1、上周复习

1.1、索引

1.1.1、聚集索引构建B树的过程

1.1.2、辅助索引构建B树的过程

1.1.3、面试题简易回答

1）一张表只能有一个聚集索引，最好是自增的数字列
2）聚集索引叶子节点有序存储的整行数据
3）辅助索引一个表可以有多个
4）辅助索引叶子节点存储的是索引列的有序值+此列值的主键值

1.1.4、辅助索引细分

1）单列辅助索引
2）多列联合索引
      --- select xxxx  from   where  a   b   c 都是等值查询，建索引有什么好的建议
       1.考虑联合索引
       2.排列问题，唯一值多的放在
        alter table t1  add idx(c,b,a)
        select count(distinct a) from t1;
        为什么？
        优化器会自动按照索引建立的顺序，自动排列where条件的顺序，前提都是等值或者in的。
        如果出现其他方式条件,比如：
出现了> < 或者group by  order by 
        怎么判断联合索引带来的优化效果？
         1.看执行计划
         2.key_len 
3）唯一索引

1.1.5、索引树高度问题(索引树高度受哪些原因影响？）开发规范

1）数据类型：char和varchar  enum
2)   数据量级问题：分库、分表、分布式
3）索引列值长度：前缀索引

1.2、explain(desc)重点回顾

1.2.1、你在你们公司做过哪些优化（mysql）？

1）我在公司主要是配合开发和业务人员，进行SQL优化和索引优化这块的工作
2）我主要是针对索引优化，这块做的比较多
3）我一般都是针对两个数据库工具进行配优化
4）第一个就是slowlog(自动收集慢语句），第二个工具就是explain
5）我通过之前做过的小案列来简单说明下我的优化思路
6）explain(desc)使用场景（面试题）
题目意思：我们公司业务慢，请你从数据库的角度分析原因
       1、MySQL突然出现性能问题，我总结有两种情况：
               1）应急性的慢：突然夯住
                  应急情况：数据库夯住（卡了，资源耗尽）
                  处理过程：
                   1、show processlist获取导致数据库hang住的SQL语句
                   2、explain,分析SQL的执行计划，检查有没有走索引，索引的类型情况
                   3、建索引，改语句
               2）一段时间的慢（持续性的）： 
                   1、记录慢日志slowlog,分析slowlog
                   2、explain,分析SQL的执行计划，检查有没有走索引，索引的类型情况
                   3、建索引，改语句
7、另外我还做一步存储引擎方面的优化
   我们有个业务是插入类的操作比较多，做过一个存储引擎方面的优化
    将innodb替换成tokudb
    主要说说为什么会使用tokudb

1.3、存储引擎

1.3.1、innodb存储引擎核心特性

事务
外键
热备份
MVCC
CSR

1.3.2、表空间管理

alter table tb1 discard tablespace;
alter table tb1 import tablespace;

1.3.3、事务特性

A   原子性
C   一致性
I   隔离性
D   持久性

1.3.4、redo在ACID中的作用

重做日志，前滚日志。主要完成ACID中的D特性，对AC也有一定的作用
存什么？
内存数据页变化的过程

1.3.5、UNDO在ACID中的作用

回滚日志，撤销日志。主要完成ACID中的D，对CI也有一定作用

1.3.6、redo-CSR前滚

MySQL : 在启动时,必须保证redo日志文件和数据文件LSN必须一致, 如果不一致就会触发CSR,最终保证一致
情况一:
我们做了一个事务,begin;update;commit.
1.在begin ,会立即分配一个TXID=tx_01.
2.update时,会将需要修改的数据页(dp_01,LSN=101),加载到data buffer中
3.DBWR线程,会进行dp_01数据页修改更新,并更新LSN=102
4.LOGBWR日志写线程,会将dp_01数据页的变化+LSN+TXID存储到redobuffer
5. 执行commit时,LGWR日志写线程会将redobuffer信息写入redolog日志文件中,基于WAL原则,
在日志完全写入磁盘后,commit命令才执行成功,(会将此日志打上commit标记)
6.假如此时宕机,内存脏页没有来得及写入磁盘,内存数据全部丢失
7.MySQL再次重启时,必须要redolog和磁盘数据页的LSN是一致的.但是,此时dp_01,TXID=tx_01磁盘是LSN=101,dp_01,TXID=tx_01,redolog中LSN=102
MySQL此时无法正常启动,MySQL触发CSR.在内存追平LSN号,触发ckpt,将内存数据页更新到磁盘,从而保证磁盘数据页和redolog LSN一值.这时MySQL正长启动
以上的工作过程,我们把它称之为基于REDO的"前滚操作"

1.3.7、undo-CSR回滚

2.锁介绍

2.1、介绍

锁定的意思，提供的是ACID中I方面的功能。需要配合undo+隔离级别一起来实现

2.2、INNODB锁级别

行级锁

2.3、扩展内容

Next   LOCK  
GAP   LOCK
悲观锁：
乐观锁：

工作中（优化章节）：需要排查锁的争用、锁等待、死锁

3、事务的隔离级别

影响到数据的读取，默认的级别是  RR模式。
transaction_isolation    隔离级别（参数）
负责的是，MVCC，读一致性问题



RR级别：解决了不可重复读问题+幻读的现象
        不可重复读问题是由undo的快照技术来解决。
       幻读现象是由：MVCC+GAP+next-lock
RC级别：读已提交，可能出现幻读，可以防止脏读
RU：读未提交，可脏读，一般不允许出现
SR：可串行化，可以防止死锁，但是并发事务性能较差


补充: 在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  buffer  刷写磁盘方式

最大安全模式：
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实例）