一、MySQL事务级别分类
- 未提交读(READ UNCOMMITTED)
- 已提交读(READ COMMITTED)
- 重复读(REPEATABLE READ)
- 串行化(SERIALIZABLE)
二、MySQL事务级别详解
2.1.READ UNCOMMITTED
未提交读，顾名思义表示的是在该隔离级别下一个事务能够读取另一个事务未提交的记录
具体表现为
- 事务1读取了一条id=1的记录，然后事务2修改了id=1的记录，并且事务2还没有提交，此时事务1再次读取id=1的记录，发现记录已经修改了，这种现象也称为脏读
- 当事务2修改了id=1的记录，事务1无法对该条记录做更新（事务会被阻塞），只能等待事务2提交之后才能修改该记录
2.2.READ COMMITTED
已提交读，只能只能够读取另一个事务提交的修改记录
具体表现
- 事务1读取了一条id=1的记录，然后事务2修改了id=1的记录，并且事务2还没有提交，此时事务1再次去读id=1的记录，记录没有变化，然后将事务2提交，在事务1中去读id=1的记录，此时记录发生了变化，这种现象也成为不可重复读
2.3.REPEATABLE READ
可重复读，从一个事务开始到提交，读取的数据不会发生变化（由于其他事务的修改）
具体表现
- 事务1读取了一条id=1的记录，然后事务2修改了id=1的记录，事务2提交与否，在事务1提交之前，都是不会发生变化的，因此REPEATABLE READ级别可以禁止不可重复
读现象的发生 - 该级别的间隙锁可以防止幻读的发生，幻读有着相应的触发条件
- 查询条件id是唯一索引，并且根据条件id查询不到相应记录
- 查询条件id是非唯一索引
2.4.SERIALIZABLE
串行化，每条指令都会进行加锁然后一条指令一条指令的运行
具体表现
- 事务1读取了一条id=1的记录，然后事务2修改id=1的记录时会被阻塞，直到事务1被提交
三、MySQL的多并发版本控制(MVCC)
MVCC是一个行级锁的变种，在很多情况下避免了加锁的操作，因此开销更低。MVCC的具体实现，是通过保存数据在某个时间点的快照来实现的
InnoDB的MVCC，是通过在每行记录后面保存两个隐藏的列来实现的。这两个列，一个保存了行的创建时间，一个保存行的过期时间(或删除时间)。存储的并不是实际的时间，而是系统的版本号。每开始一个新的事务，系统版本号会自动递增。
MVCC只有在READ COMMITTED和REPEATABLE READ这两个隔离级别才有效，因为READ UNCOMMITTED和SERIALIZABLE这两个级别前者是读取最新的数据，后者是对所有的读取的行都加锁，所以针对这两个级别，MVCC无效
MVCC会根据以下两个条件来检索每行记录
- InnoDB只查找版本早于当前版本的数据行（也就是，行的版本号小于或等于事务的系统版本号），这样可以确保事务读取的行，要么是在事务开始前已经存在的，要么是事务自身插入或者修改的
- 行的删除版本要么未定义，要么大于当前事务版本。这可以确保事务读取到的行，在事务开始之前未被删除
四、ReadView
在innodb中，在MVCC有效的隔离级别查找数据(select * from table)时会创建一个
ReadView，然后将数据库中的数据和ReadView中作对比，以此判断该行数据是否可见
ReadView
- m_ids[]:保存活跃的事务（未提交的事务）
- min_trx_id:获取读写事务中最小的事务id，也是m_ids中最小的id
- max_trx_id:应该分配给下一个事务的id(已经存在最大事务id+1)
- creator_trx_id:生成read view的事务id
ReadView判断可见性算法
- 如果被访问版本的trx_id属性值小于min_trx_id,说明生成该版本的事务在生成ReadView前已经提交，所以该版本可以被当前事务访问
- 如果被访问版本的trx_id属性值大于max_trx_id，说明生成该版本的事务在生成ReadView后才生成，所以该版本不能被当前事务访问
- 如果被访问版本的trx_id属性值处于min_trx_id和max_trx_id之间，首先判断trx_id是否等于creator_trx_id，如果是说明是当前事务产生的数据可见，如果不是判断trx_id是否在m_ids中（事务是否处于活跃状态），如果是说明事务未提交不可见，在undo日志里面找上一个版本的old_trx_id然后赋值给trx_id，从第一步进行判断，如果trx_id不在m_ids中（事务已经提交）,该版本可以被访问
READ COMMITED和REPEATABLE READ的区别在于生成ReadView的机制不同，READ COMMITTED每次select数据的时候都会重新生成一个新的ReadView而REPEATABLE READ是事务开始前select数据，在事务提交之前所有的select都复用第一次生成的ReadView所以事务中查看的数据都是一样的
查询结果底层分析
以提交读级别为例分析出现的结果
[图片上传失败...(image-6c71e0-1572695701127)]
- 数据库中已经存在一条记录
| id | name | trx_id | rollback_id |
|---|---|---|---|
| 1 | 张一 | trx_1 | null |
- 开始两个事务trx_2，trx_3，通过read view可见性算法克制，trx_0小于这两个
事务中的min_trx_id，因此这条记录在两个事务中全部可见，此时，trx_3修改id=1的name值，此时记录变成了如下情况
| id | name | trx_id | rollback_id |
|---|---|---|---|
| 1 | 张一 | trx_1 | null |
| 1 | 张一1 | trx_3 | trx_1 |
- 此时在trx_2的事务中，trx_2<trx_3<trx_4,并且不等于trx_2，并且在trx_2事务中的m_ids中(属于未提交的事务)，因此这条记录对于trx_2不可见，通过rollback_id回溯到trx_1，这条记录对trx_2可见，因此trx_2中查询还是之前的记录
- trx_3事务提交之后，trx_2再次查询,不同的事务级别会产生不同的结果
- READ COMMITTED会重新创建一个READ COMMITTED，此时trx_3不在ReadView中
的m_ids中，因此修改记录对trx_2可见 - REPEATABLE READ还是沿用上一个ReadView，trx_3还是存在于m_ids中，修改
记录还是对trx_2不可见
- READ COMMITTED会重新创建一个READ COMMITTED，此时trx_3不在ReadView中
三、总结
从上边的描述中我们可以看出来，所谓的MVCC（Multi-Version Concurrency Control ，多版本并发控制）指的就是在使用READ COMMITTD、REPEATABLE READ这两种隔离级别的事务在执行普通的SEELCT操作时访问记录的版本链的过程，这样子可以使不同事务的读-写、写-读操作并发执行，从而提升系统性能。READ COMMITTD、REPEATABLE READ这两个隔离级别的一个很大不同就是生成ReadView的时
机不同，READ COMMITTD在每一次进行普通SELECT操作前都会生成一个ReadView，而REPEATABLE READ只在第一次进行普通SELECT操作前生成一个ReadView，之后的查询操作都重复这个ReadView就好了
以上的结论是笔者查阅了大量资料以及试验所得，如果误差，欢迎一起探讨
