MySQL+InnoDB semi-consitent read原理及实现分析
semi-consistent简介
对于熟悉MySQL，或者是看过InnoDB源码的朋友们来说，可能会听说过一个新鲜的名词：semi-consistent read 。 何谓semi-consistent read？以下一段文字，摘于semi-consistent read一文：
A type of read operation used for UPDATE statements, that is a combination of read committed and consistent read. When an UPDATE statement examines a row that is already locked, InnoDB returns the latest committed version to MySQL so that MySQL can determine whether the row matches the WHERE condition of the UPDATE. If the row matches (must be updated), MySQL reads the row again, and this time InnoDB either locks it or waits for a lock on it. This type of read operation can only happen when the transaction has the read committed isolation level, or when the innodb_locks_unsafe_for_binlog option is enabled.
简单来说，semi-consistent read是read committed与consistent read两者的结合。一个update语句，如果读到一行已经加锁的记录，此时InnoDB返回记录最近提交的版本，由MySQL上层判断此版本是否满足update的where条件。若满足(需要更新)，则MySQL会重新发起一次读操作，此时会读取行的最新版本(并加锁)。
semi-consistent read只会发生在read committed隔离级别下，或者是参数innodb_locks_unsafe_for_binlog被设置为true。
MySQL server与InnoDB引擎是如何进行交互？InnoDB引擎如何实现semi-consistent read？请见下面的详细分析。
semi-consistent实现
MySQL Server层
从上面的描述中可以看出，semi-consistent read仅仅针对于update操作，因此在sql_update.cc的mysql_update方法中，有如下调用：
sql_update.cc::mysql_update()
// 通知底层引擎，尝试进行semi consistent read
// 是否真正进行semi consistent read，由底层引擎决定
table->file->try_semi_consistent_read(1);
// InnoDB引擎决定当前update是否可以进行semi-consistent read
// 具体的处理方法，在下节中分析
ha_innodb.cc::try_semi_consistent_read(bool yes);
// 进行update的读与更新操作
…
// update操作完成之后，关闭semi-consistent read
table->file->try_semi_consistent_read(0);
MySQL Server层处理semi-consistent较为简单，接下来看看InnoDB Engine的处理方式。
InnoDB Engine层
InnoDB Engine层面，对于semi-consistent read的处理，包括两方面的逻辑：
- 判断当前语句是否可以支持semi-consistent read
- fetch next时，对于semi-consistent read的特殊处理
是否采用semi-consistent read
前面提到，MySQL Server在update时，会调用引擎的try_semi_consistent_read方法，来尝试进行semi-consistent read，而是否进行semi-consistent read，则交由底层处理。
ha_innodb.cc::try_semi_consistent_read()
if (yes &&
(srv_locks_unsafe_for_binlog
|| prebuilt->trx->isolation_level <= TRX_ISO_READ_COMMITTED))
prebuilt->row_read_type = ROW_READ_TRY_SEMI_CONSISTENT;
简单分析下，当用户设置系统参数innodb_locks_unsafe_for_binlog为true，或者是采用的事务隔离级别为read committed(或以下)时，设置prebuilt->row_read_type参数，标识当前update语句使用semi-consistent read，fetch next时需要有针对性的做特殊处理。
Fetch Next特殊处理逻辑
InnoDB fetch next的主函数入口是row_search_for_mysql，此函数如何针对性的处理semi-consistent read呢？
row0sel.c::row_search_for_mysql()
…
// 尝试对于定位到的记录加锁
err = sel_set_rec_lock();
…
case DB_LOCK_WAIT:
// 如果加锁需要等待，则判断是否可以进行semi-consistent read
// 判断条件为：
// 1. prebuilt->row_read_type必须设置为ROW_READ_TRY_SEMI_CONSISTEN
// 2. 当前scan必须是range scan或者是全表扫描，而非unique scan
// 3. 当前索引必须是聚簇索引
// 4. 不满足以上三个条件，就不能进行semi-consistent read，进行加锁等待
// 注意：若不需要加锁等待，那么也不需要进行semi-consistent read，直接
// 读取记录的最新版本即可，没有加锁等待的开销。
if ((prebuilt->row_read_type != ROW_READ_TRY_SEMI_CONSISTENT)
|| unique_search
|| index != clust_index)
goto lock_wait_or_error;
// 可以进行semi-consistent read，根据记录的当前版本，构造最新的commit版本
// 若没有commit版本，当前版本为最新版本，则直接读取下一条记录
// 若存在commit版本，则设置did_semi_consistent_read为TRUE
row_sel_build_committed_vers_for_mysql();
if (old_vers == NULL)
goto next_rec;
did_semi_consistent_read = TRUE;
…
// 若本次update scan，由于加锁等待，使用了semi-consistent，则设置相应的参数
// 该参数，在下一小节提到的MySQL针对semi-consistent优化中有用
if (did_semi_consistent_read)
prebuilt->row_read_type = ROW_READ_DID_SEMI_CONSISTENT;
else
prebuilt->row_read_type = ROW_READ_TRY_SEMI_CONSISTENT;
// 至此，InnoDB的fetch next针对semi-consistent read的处理完毕
优化：Unlock unmatched row
上面提到的是semi-consistent read的功能实现，除此之外，MySQL针对semi-consistent read，还做了优化措施：对于update scan返回的不满足条件的记录，提前放锁。
MySQL Server层流程：
sql_update.cc::mysql_update()
// 判断当前scan返回的记录，是否满足update的where条件
// 若满足，则进行update操作
if (!(select && select->skip_record())
…
// 若不满足update的where条件，则选择将当前记录上的行锁提前释放
else
table->file->unlock_row();
InnoDB Engine层流程：
ha_innobd.cc::unlock_row();
switch (prebuilt->row_read_type)
// 若系统未设置参数innodb_locks_unsafe_for_binlog，同时隔离级别大于
// TRX_ISO_READ_COMMITTED，则不可提前释放不满足条件的行锁
// 否则可以提前释放不满足条件的行锁
case ROW_READ_WITH_LOCKS:
if (!srv_locks_unsafe_for_binlog &&
prebuilt->trx->isolation_level > TRX_ISO_READ_COMMITTED)
break;
// 若当前系统已采用SEMI_CONSISTENT read，但是没有锁等待，加锁直接成功
// 那么此时直接释放不满足条件的行锁
case ROW_READ_TRY_SEMI_CONSISTENT:
row_unlock_for_mysql();
// 若当前系统已采用SEMI_CONSISTENT read，并且有锁等待，构造了commit版本
// 没有在commit版本上加锁，因此也无锁可放，直接返回即可
case ROW_READ_DID_SEMI_CONSISTENT:
prebuilt->row_read_type = ROW_READ_TRY_SEMI_CONSISTENT;
break;
semi-consistent优缺点分析
优点
- 减少了更新同一行记录时的冲突，减少锁等待。
无并发冲突，读记录最新版本并加锁；有并发冲突，读事务最新的commit版本，不加锁，无需锁等待。
- 可以提前放锁，进一步减少并发冲突概率。
对于不满足update更新条件的记录，可以提前放锁，减少并发冲突的概率。
- 在理解了semi-consistent read原理及实现方案的基础上，可以酌情考虑使用semi-consistent read，提高系统的并发性能。
缺点
- 非冲突串行化策略，因此对于binlog来说，是不安全的
两条语句，根据执行顺序与提交顺序的不同，通过binlog复制到备库后的结果也会不同。不是完全的冲突串行化结果。
因此只能在事务的隔离级别为read committed(或以下)，或者设置了innodb_locks_unsafe_for_binlog参数的情况下才能够使用。
测试用例
构造semi-consistent read
set binlog_format=mixed;
set session transaction isolation level repeatable read;
create table t1(a int not null) engine=innodb DEFAULT CHARSET=latin1;
insert into t1 values (1),(2),(3),(4),(5),(6),(7);
session 1: session 2:
set autocommit=0;
update t1 set a = a + 10;
set binlog_format=mixed;
set session transaction isolation level read committed;
update t1 set a = a + 100 where a > 10;
此时，session 2不需要等待session 1，虽然session 1的更新后项满足session 2的条件，但是由于session 2进行了semi-consistent read，读取到的记录的前项为(1-7)，不满足session 2的更新where条件，因此session 2直接返回。
session 2直接返回，0 rows affected。
构造unlock unmatched row
set binlog_format=mixed;
set session transaction isolation level repeatable read;
create table t1(a int not null) engine=innodb DEFAULT CHARSET=latin1;
insert into t1 values (1),(2),(3),(4),(5),(6),(7);
session 1: session 2:
set autocommit=0;
update t1 set a = a + 10;
commit;
set binlog_format=mixed;
set session transaction isolation level repeatable read;
set autocommit = 0;
update t1 set a = a + 100 where a < 10;
select * from t1 lock in share mode;
session 1在session 2开始前已经提交，session 2可以进行semi-consistent read。并且读到的都是session 1的更新后项，完成加锁。但是由于更新后项均不满足session 2的where条件，session 2会释放所有行上的锁(由MySQL Server层判断并调用unlock_row方法释放行锁)。
此时，session 1再次执行select * from t1 lock in share mode语句，直接成功。因为session 2已经将所有的行锁提前释放。
朋友们可以试试将session 2的隔离级别改为repeatable read，那么此时session 1就会等待session 2提交。