MySQL性能调优
- 1. MVCC多版本并发控制机制
- 1.1 undo日志版本链与read view机制详解
- 2. Innodb引擎SQL执行的BufferPool缓存机制
本文是按照自己的理解进行笔记总结，如有不正确的地方，还望大佬多多指点纠正，勿喷。
本节课内容：
1、Undo日志版本链与Read View机制详解
2、MVCC多版本并发控制机制详解
3、Innodb引擎BufferPool缓存机制详解
4、Redo与Undo日志详解
1. MVCC多版本并发控制机制
Mysql在可重复读隔离级别下如何保证事务较高的隔离性，我们上节课给大家演示过，同样的sql查询语句在一个事务里多次执行查询结果相同，就算其它事务对数据有修改也不会影响当前事务sql语句的查询结果。
这个隔离性就是靠MVCC(Multi-Version Concurrency Control)机制来保证的，对一行数据的读和写两个操作默认是不会通过加锁互斥来保证隔离性，避免了频繁加锁互斥，而在串行化隔离级别为了保证较高的隔离性是通过将所有操作加锁互斥来实现的。
Mysql在读已提交和可重复读隔离级别下都实现了MVCC机制。
1.1 undo日志版本链与read view机制详解
undo日志版本链是指一行数据被多个事务依次修改过后，在每个事务修改完后，Mysql会保留修改前的数据undo回滚日志，并且用两个隐藏字段trx_id和roll_pointer把这些undo日志串联起来形成一个历史记录版本链(见下图，需参考视频里的例子理解)
我的理解，就是一行数据被多个事务进行修改，每次修改之后会生成一条undo日志，日志中里包含trx_id和roll_pointer两个隐藏字段，roll_pointer会指向之前的事务修改日志，通过指针和undo串联起来形成日志版本链
在可重复读隔离级别，当事务开启，执行任何查询sql时会生成当前事务的一致性视图read-view，该视图在事务结束之前都不会变化(如果是读已提交隔离级别在每次执行查询sql时都会重新生成)，这个视图由执行查询时所有未提交事务id数组（数组里最小的id为min_id）和已创建的最大事务id（max_id）组成，事务里的任何sql查询结果需要从对应版本链里的最新数据开始逐条跟read-view做比对从而得到最终的快照结果。
版本链比对规则：
- 如果 row 的 trx_id 落在绿色部分( trx_id<min_id )，表示这个版本是已提交的事务生成的，这个数据是可见的；
- 如果 row 的 trx_id 落在红色部分( trx_id>max_id )，表示这个版本是由将来启动的事务生成的，是不可见的(若 row 的 trx_id 就是当前自己的事务是可见的）；
- 如果 row 的 trx_id 落在黄色部分(min_id
<=trx_id<=max_id)，那就包括两种情况
a. 若 row 的 trx_id 在视图数组中，表示这个版本是由还没提交的事务生成的，不可见(若 row 的 trx_id 就是当前自己的事务是可见的)；
b. 若 row 的 trx_id 不在视图数组中，表示这个版本是已经提交了的事务生成的，可见。
对于删除的情况可以认为是update的特殊情况，会将版本链上最新的数据复制一份，然后将trx_id修改成删除操作的trx_id，同时在该条记录的头信息（record header）里的（deleted_flag）标记位写上true，来表示当前记录已经被删除，在查询时按照上面的规则查到对应的记录如果delete_flag标记位为true，意味着记录已被删除，则不返回数据。
快照试图第一次查到啥就是啥，除非commit重新查询，由于MVCC机制与undo日志版本链会使其是这个结果。
总结：
MVCC机制的实现就是通过read-view机制与undo版本链比对机制，使得不同的事务会根据数据版本链对比规则读取同一条数据在版本链上的不同版本数据。
如果是读已提交隔离级别，也是MVCC机制但是是按照另一套逻辑来处理的
readview都是针对当前事务生成的，是在你实际查询的时候生成的，不是你begin的时候生成的，是针对整个数据库的，你单独查另一张表b，然后在a表进行修改，再次去查a表的数据，显示的是修改前的数据，针对这个时候select会生成readreview
不可重复读的readview是每个事务都有一份，但是对于数据的版本链只有一份。
2. Innodb引擎SQL执行的BufferPool缓存机制
为什么Mysql不能直接更新磁盘上的数据而且设置这么一套复杂的机制来执行SQL了？
因为来一个请求就直接对磁盘文件进行随机读写，然后更新磁盘文件里的数据性能可能相当差。
因为磁盘随机读写的性能是非常差的，所以直接更新磁盘文件是不能让数据库抗住很高并发的。
Mysql这套机制看起来复杂，但它可以保证每个更新请求都是更新内存BufferPool，然后顺序写日志文件，同时还能保证各种异常情况下的数据一致性。
更新内存的性能是极高的，然后顺序写磁盘上的日志文件的性能也是非常高的，要远高于随机读写磁盘文件。
正是通过这套机制，才能让我们的MySQL数据库在较高配置的机器上每秒可以抗下几干甚至上万的读写请求。
其他
- ACID就是为了我们写代码方便，如果数据总是变动，这样很麻烦，没办法写代码
- 串行化是加锁，用到的相同数据，串行执行，整张表的所有数据加锁，数据插不进来，他是针对你查询的sql语句加锁，你查出几条记录就加哪几条记录的锁，对你操作的数据加锁，操作的数据不能动，比如你查id为1的数据，或者你插入id为6的数据，这两个数据如果在事务中的话，其他线程是对这两条数据不能操作的，阻塞中
- 串行化效率低
