mysql隔离级别实现原理探究
关于这个话题，在网上看到了多种说法，总是撸不通思路，于是决定自己探究，先把结论贴出来
未提交读写时加排他锁，写完释放；（读时不加锁；）
提交读写时加排他锁，事务结束后释放
读时通过mvcc，访问的是创建版本最大&&删除版本为空的记录
重复读写时加排他锁，事务结束后释放
读时通过mvcc，访问的是创建版本小于等于当前版本&&（删除版本大于当前版本 || 删除版本为空）的记录
结论纯粹是个人推测出来的，凭个人的实验验证和进一步的猜想得来，但不一定就是正确的！！！
简单验证一下提交读情况下，写时加排他锁，事务结束后释放的情况：
事务1和事务2是基于相同的背景的，关闭了自动提交，设置隔离级别为提交读，然后开始了事务。
接下来我们可以看到，事务2对id为1的记录做了修改，这个时候并没有提交，此时事务1也尝试对该记录做修改，但却失败了，报错说锁等待超时。
之后我将事务2提交了，事务1再次执行修改语句，成功了。
从上面的实验可以得出一个结论，隔离级别为提交读的情况下，对记录的修改会加上排他锁，且直到事务结束时才释放。
其他隔离级别下的写时加锁情况可以依据上面的实验去推出结论，请有兴趣的读者自行验证。
至于读时加锁或者借助mvcc机制的情况，等我进一步学习mvcc后再来补充。
https://blog.csdn.net/aigoogle/article/details/42558075谷歌搜到这篇博文与本文的思想是一样的。
继续探究了mysql的mvcc实现后，有了一些新的理解：
在mysql内部维护着很多的日志表，其中有一个叫做undo日志表（记录原始数据，主要用于事务回滚操作，也可以用于mvcc机制），同时还使用了一个叫做read view的表来做可见性判断。
在mysql中，mvcc是通过在表中插入三个隐藏字段实现的，这三个隐藏字段如下：
6字节的事务ID DB_TRX_ID）
7字节的回滚指针（DB_ROLL_PTR）
隐藏的ID
假设我们有记录如下
图片来源于第一篇参考文章
现在我们开启一个事务1，并对该记录做修改
图片来源于第一篇参考文章
这个时候如果有另外一个事务2，并且这个事务2的版本小于事务1，现在，事务1要查询这条记录。
在真实表中，数据已被修改，但因为事务2的版本小于事务1的版本，这条修改对事务2来说是不可见的，于是就根据这条记录的回滚id找到了undo log中原来的数据。
在真实情况中，并发的事务数量大，对数据的可见性需要统一管理，于是就有了read view。
在可重复读级别下，开启一个事务，这个时候mysql就要将此刻所有活跃的事务拷贝到一个新的read view表中， 假定其中最大最小的事务版本号分别为max_id,min_id，现要查询的记录版本号为trx_id。有以下几种情况：
1、trx_id<min_id，说明在开启事务前，记录已存在，可见。
2、trx_id>max_id，说明在开启事务时，记录还不存在，不可见。
3、min_id<trx_id<max_id，这时候我们需要遍历read view表，看看是否有对应的事务版本号。如果有，说明在开启事务时，记录处于活跃状态，此时需要对照回滚id，找到undo表中相应的记录。如果没有，说明开启事务时，修改了该条记录的另一个事务已经结束，记录可见。
在提交读的级别下，不同的地方在于每次执行语句时，都会重新计算一个新的read view表，这样就可以达到读取已提交记录的目的。
参考文章：http://www.imooc.com/article/17290
https://liuzhengyang.github.io/2017/04/18/innodb-mvcc/
网友评论