简单介绍innodb的四种隔离级别（innodb中的隔离级别，与sql规范的隔离级别有一点点不同）

排序从常用到最不常用：

• REPEATABLED READ
  innodb默认级别，能保证同一事务中，执行同一条查询记录，读取到的都与第一次执行所查询的数据一致。但是部分的update/delete还是存在幻读，即并没有完全解决幻读，但是解决了一部分
• READ COMMITTED
  提交了就能读，存在幻读
• READ UNCOMMITTED
  未提交就能读，存在脏读和幻读
• SERIALIZABLE
  啥读都没有，很安全但是效率很低

事务隔离级别实现原理

本文只探讨最常用的REPEATABLED READ和READ COMMITTED实现原理

一、MVCC

MVCC是一个多版本并发控制标准，每种数据库都有其自己的实现，在MySQL当中，MVCC包括：

1. 版本链，对于innodb，每个记录中都包含三个必要的隐藏列：
   • row_id: 行ID，唯一标识一条行记录，6字节
   • transaction_id: 每次改动某条记录，都会把对应的事务id赋值给该列，6字节
   • roll_pointer: 回滚指针，每次改动某条记录，这个隐藏列会存一个指针，可以通过这个指针找到该记录修改前的信息，7字节，roll_pointer连接成版本链：
     
     image.png
2. 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

image.png

但是这种做法并不推荐，一方面幻读大部分场景是可以接受的，另一方面这样上锁相当于串行执行，大大降低吞吐量。

总结

• read committed无论是select还是update都无法避免幻读的问题。repeatable用MVCC来避免了select时的幻读，并用默认上临键锁的方式，避免了部分情况的幻读，然而并没有完全解决，除非切换到串行隔离级别，或手动上锁。
• 其实大部分场景当中，幻读都是可以接受的，同一个事务中可重复读的需求也没有那么强烈，因此有时候可以考虑将repeatable read改成read committed，一方面能将锁的级别降为行锁，增加吞吐量，另一方面还能避免区间锁带来的一些死锁问题。事实上，有的数据库默认使用的就是read committed（如oracle）

思考

• repeatable为什么要默认用临键锁呢？仅仅是为了解决少数情况下会发生的幻读情况吗？为了解决幻读而增加了锁的成本，真的有必要吗？
• 即然MVCC能够解决select的幻读，为什么不将其应用到update/insert/delete的条件语句上面呢？

注：

本文部分参考MySQL官网 Transaction Isolation Levels