从锁和MVCC的角度分析MySQL InnoDB事务模型——事务
简单介绍innodb的四种隔离级别（innodb中的隔离级别，与sql规范的隔离级别有一点点不同）
排序从常用到最不常用：
-
REPEATABLED READ
innodb默认级别，能保证同一事务中，执行同一条查询记录，读取到的都与第一次执行所查询的数据一致。但是部分的update/delete还是存在幻读，即并没有完全解决幻读，但是解决了一部分 -
READ COMMITTED
提交了就能读，存在幻读 -
READ UNCOMMITTED
未提交就能读，存在脏读和幻读 -
SERIALIZABLE
啥读都没有，很安全但是效率很低
事务隔离级别实现原理
本文只探讨最常用的REPEATABLED READ和READ COMMITTED实现原理
一、MVCC
MVCC是一个多版本并发控制标准，每种数据库都有其自己的实现，在MySQL当中，MVCC包括：
- 版本链，对于innodb，每个记录中都包含三个必要的隐藏列：
- row_id: 行ID，唯一标识一条行记录，6字节
- transaction_id: 每次改动某条记录，都会把对应的事务id赋值给该列，6字节
- roll_pointer: 回滚指针，每次改动某条记录，这个隐藏列会存一个指针，可以通过这个指针找到该记录修改前的信息，7字节，roll_pointer连接成版本链：
image.png
- readView：使用select的时候会生成readview，保存执行select时，还未提交的事务id数组。
在read committed隔离级别当中，同一个事务，每次执行select，都会产生一个readView对象，查询的时候，只查询事务id小于当前事务id的记录，并过滤readView中的事务id，以此来避免脏读。但是会有一些特殊情况，如图：
image.png
也就是幻读的情况
repeatable read其他方面都与read committed一致，之所以能够避免幻读，是因为它只在第一次select的时候生成一个readView。
但是，MVCC仅仅解决来于select的幻读，在update/delete/insert命令中的where条件查询，并没有用到MVCC，而是通过锁来解决部分情况的幻读
二、锁
在read committed当中，update/delete/insert时用到的是行锁，只锁住条件匹配到的指定数据（如update t1 set a = 1 where user_id = 1只锁住user_id等于1的行数据），这样到好处是效率更高，锁的粒度是行级别，但是会存在以下问题：
-
read committed写数据幻读问题演示
假设有一张表t1结构和数据为：
image.png
数据库操作如下：
image.png
可以看到，事务2在select的时候明明只查到三条数据，但是执行update的时候却影响了四条数据，这也是幻读的一种形式，导致该现象的原因是innodb的update没有使用MVCC，且read committed级别只使用了行锁。
而在repeatable read当中，执行update/delete/insert操作时，如果条件语句用到的是唯一索引，则使用行锁，否则默认会用到临键锁（Next-key lock），即将匹配行对应的上下区间数据锁住（对临键锁有疑惑可以戳这里），上面的情况就会变成：
image.png
因此，repreatable read当中，能够避免select的幻读，也能避免上面这种情况的幻读，但是并不能完全解决幻读的问题（在我们不手动上锁的情况下），如下面这种情况：
image.png
这种情况下，即使有临键锁也无法避免幻读，除非我们在事务2执行select的时候就对数据区间上锁，即将select语句改成：
select * from t1 where user_id > 20 for update（注意select ... for update会显示地给数据加锁，在read committed加行锁，repeatable read加区间锁），这样一来，事务2 执行select的时候，其他事务就无法在区间内插入数据，后面的update语句也就不会出现幻读的情况。
但是这种做法并不推荐，一方面幻读大部分场景是可以接受的，另一方面这样上锁相当于串行执行，大大降低吞吐量。
总结
- read committed无论是select还是update都无法避免幻读的问题。repeatable用MVCC来避免了select时的幻读，并用默认上临键锁的方式，避免了部分情况的幻读，然而并没有完全解决，除非切换到串行隔离级别，或手动上锁。
- 其实大部分场景当中，幻读都是可以接受的，同一个事务中可重复读的需求也没有那么强烈，因此有时候可以考虑将repeatable read改成read committed，一方面能将锁的级别降为行锁，增加吞吐量，另一方面还能避免区间锁带来的一些死锁问题。事实上，有的数据库默认使用的就是read committed（如oracle）
思考
- repeatable为什么要默认用临键锁呢？仅仅是为了解决少数情况下会发生的幻读情况吗？为了解决幻读而增加了锁的成本，真的有必要吗？
- 即然MVCC能够解决select的幻读，为什么不将其应用到update/insert/delete的条件语句上面呢？
