1. 上周重点难点回顾
1.1 索引
聚集索引构建B树的过程
辅助索引构建B树的过程
面试问题简易回答?
--- 请你简述，InnoDB 聚集索引和辅助索引的区别？ *****
- 一张表只能有一个聚集索引，最好是自增的数字列
- 聚集索引叶子节点有序存储的整行数据
- 辅助索引一个表可以有多个
- 辅助索引叶子节点存储的是索引列的有序值+此列值的主键值
想要详细回答，整个两个索引构建的过程和配合使用，最好是画图说明
辅助索引细分
单列辅助索引
多列联合索引 *****
--- select xxxx from where a b c 都是等值查询，建索引有什么好的建议
- 考虑联合索引
- 排列问题? 唯一值多的放在
alter table t1 add idx(c,b,a)
select count(distinct a) from t1;
为什么？
优化器会自动按照索引建立的顺序，自动排列 where 条件的顺序，前提是都是等值或者in的。
如果出现其他方式条件,比如：
出现了> < 或者group by order by
怎么判断联合索引将来的优化效果？
- 看执行计划
- key_len
唯一索引
索引树高度问题
--- 索引树高度受到哪些原因影响？（开发规范）
- 数据类型： char varchar enum
- 数据量级问题： 分库 分表 分布式
- 索引列值长度： 前缀索引
前缀索引
explain(desc)重点回顾
--- 你在你们公司做过哪些优化（MySQL）?
- 我在公司，主要是配合开发和业务人员，进行SQL优化和索引优化这块的工作
- 我主要针对索引优化这块儿，做的工作比较多
- 我一般都是配合两个数据库工具进行配优化
- 第一个就是slowlog（自动收集慢语句），第二个工具是explain
- 我通过之前做过的小案例来简单说明下我的优化思路
- explain(desc)使用场景（面试题）
题目意思: 我们公司业务慢,请你从数据库的角度分析原因
1.mysql出现性能问题,我总结有两种情况:
（1）应急性的慢：突然夯住
应急情况:数据库hang(卡了,资源耗尽)
处理过程:
1.show processlist; 获取到导致数据库hang的语句 - explain 分析SQL的执行计划,有没有走索引,索引的类型情况
- 建索引,改语句
（2）一段时间慢(持续性的):
记录慢日志slowlog,分析slowlog
explain 分析SQL的执行计划,有没有走索引,索引的类型情况
建索引,改语句
另外，我还做一部分存储引擎方面的优化。
我们有个业务是插入类的操作比较多，做过了一个存储引擎方面的优化。
将innoDB替换成了tokuDB
主要说说为什么会使用tokudb
。。。。。。
1.2 存储引擎
InnoDB存储引核心特性
Transaction，Row Level Lock，MVCC，CSR，FK，HB，Replication
表空间管理
alter table t1 discard tablespace;
alter table t1 import tablespace;
事务特性
A 原子
C 一致
I 隔离
D 持久
redo在ACID中的作用
重做日志，前滚日志。主要完成ACID中的D的特性。对AC也有一定的作用
存什么？
内存数据页变化的过程
Undo在ACID作用
回滚日志，撤销日志。主要完成的ACID中的A，对CI也有一定的作用
redo-CSR前滚
Undo-CSR回滚
今日预计内容
2. 锁介绍
2.1 介绍
锁定的意思，提供的是ACID中，I方面的功能。需要配合UnDO+隔离级别一起来实现
2.2 InnoDB锁级别
行级锁
2.3 扩展内容(自己扩展)
Next LOCK
GAP LOCK
悲观锁：
乐观锁：
第一种：
select id from t where id > 9 and id < 12 order by id for update
访问顺序 ：
- id=9,gap [5-10]
- 向右遍历 next-lock 10-15，发现10>9,停止扫描，但由于不是等值12，所有next-lock保持不变更gap
最终锁范围： [5-10],[10-15] ====》 [5-15]
第二种
select id from t where id > 9 and id < 12 order by id desc for update
由于order by desc 的存在，查询优化器为了避免再排一次序，会将查找顺序优化为先找id <12
所以访问顺序
- id=12 ，gap[10-15]
- 向左遍历，next-lock ，扫到5-10范围，发现10>9,继续向左,扫到0-5，发现5<9,停止扫描
但由于不是等值9，所有next-lock保持不变更gap
最终锁范围： [0-5],[5-10],[10-15] ===> [0-15]
工作中（优化章节）：需要排查锁的争用、锁等待、死锁
3. 事务的隔离级别
影响到数据的读取,默认的级别是 RR模式.
transaction_isolation 隔离级别(参数)
负责的是,MVCC,读一致性问题
RU : 读未提交,可脏读,一般部议叙出现
RC（*****） : 读已提交,可能出现幻读,可以防止脏读.
RR（*****） : 可重复读,功能是防止"幻读"现象 ,利用的是undo的快照技术+GAP(间隙锁)+NextLock(下键锁)
SR : 可串行化,可以防止死锁,但是并发事务性能较差
RR级别：解决了 不可重复读问题+幻读的现象
不可重复读问题是由 undo的快照技术来解决。
幻读现象是由：MVCC+GAP+next-lock
补充: 在RC级别下,可以减轻GAP+NextLock锁的问题,但是会出现幻读现象,一般在为了读一致性会在正常
select后添加for update语句.但是,请记住执行完一定要commit 否则容易出现所等待比较严重.
例如:
[world]>select * from city where id=999 for update;
[world]>commit;
******欠一个问题，关于幻读模拟。******
4. InnoDB核心参数
4.1 双一标准之一(*****)：innodb_flush_log_at_trx_commit=1
作用：
控制了redo buffer 刷写策略，是一个安全参数，是在5.6版本以上默认的参数
参数功能
1：每次事务提交，都会立即刷下redo到磁盘（redo buffer --每事务-->os buffer --每事务--磁盘）
0：表示当事务提交时，不立即做日志写入操作（redo buffer --每秒-->os buffer --每秒--磁盘）
2：每次事务提交引起写入文件系统缓存（redo buffer --每事务-->os buffer --每秒--磁盘）
4.2 Innodb_flush_method=(O_DIRECT, fdatasync)
作用：
控制了 redo buffer 和 data bufffer 刷写磁盘方式
最大安全模式：
innodb_flush_log_at_trx_commit=1
innodb_flush_method=O_DIRECT
最大性能模式：
innodb_flush_log_at_trx_commit=0
innodb_flush_method=fsync
4.3 关于redo设置
innodb_log_buffer_size= 128M 业务系统CPU压力有关
innodb_log_file_size=256 一般是1-2倍
innodb_log_files_in_group = 3 3-4组
4.4 innodb_buffer_pool_size
生产一般调整为物理内存的50%-80%左右（你的系统中只有一个mysql实例）
