MySQL InnoDB中的consistent read和Locking Reads

MySQL InnoDB中的consistent read和Locking Reads

MySQL InnoDB中的read 操作分为consistent read和Locking Reads，前者不需要对读取到的行加锁，后者需要加锁。

consistent read

consistent read 根据某个时间点的snapshot信息来返回结果。如果查询的数据被其他的事务修改了，那么会根据undo log来重新生成原始的数据。consistent read 不会对访问的行加锁，有助于提高并发。InnoDB处理普通的SELECT语句时，默认采用的就是consistent read，这种Read方式仅在Read committed和Repeatable Read隔离级别下工作。它是通过MVCC来实现的。

Locking Reads

SELECT ... LOCK IN SHARE MODE和SELECT ... FOR UPDATE都属于Locking Reads，顾名思义，它俩都需要对结果集加锁。关于加锁的例子，前面已经介绍过了。链接

这里简介一下consistent read的实现。采用的方法叫做MVCC(multi-versioned concurrency control),MVCC这个概念并非是MySQL独有的。如果一条记录发生了变化，我们把它变化之前的内容叫做老版本，InnoDB会把老版本信息放到一个叫做rollback segment的数据结构中，rollback segment可以实现两个功能： rollback和consistent read。
具体实现上，InnoDB在表的每条记录里都额外增加三个字段（而非《高性能MySQL》中说的两个字段）
6-byte DB_TRX_ID :最后insert或者update记录的transaction的transaction ID，delete操作会被当作update操作，只是删除位设为1
7-byte DB_ROLL_PTR：指针，指向rollback segment里的undo log record，如果一条记录被更新了，还可以通过undo log record来获取修改之前的记录
6-byte DB_ROW_ID：每当有新行插入时, row id就会加1。如果有InnoDB自动产生的clustered index，那么clustered index中包含了DB_ROW_ID，否则DB_ROW_ID 不在任何索引中增加。

rollback segment中undo logs的分类

Undo logs分为insert undo logs和update undo logs。 insert undo log仅仅用来做rollback操作，只要事务提交了，就可以丢弃。而update undo logs还可以用来consistent read，只有其他应用都不再用它作consistent read的snapshot时，才可以丢弃。因此，应用要经常提交，即使只有consistent read，这样rollback segment就可以及时丢弃update undo log。（如果undo log一直增加，可能会撑爆表空间）

更详细的原理，可以参考下面的博客和链接：
http://hedengcheng.com/?p=148
http://www.jianshu.com/p/fd51cb8dc03b
https://dev.mysql.com/doc/refman/5.7/en/innodb-locking-reads.html