一个Innodb 事务可见性问题

最近碰到的一个innodb事务可见性的问题，以前没关注过，周末过下代码，顺便记录下。

假定如下表：

CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 INT, c3 INT, key(c2));

考虑如下执行序列

Session 1:

BEGIN;

INSERT INTO t1 VALUES (1,2,3);

Session 2:

BEGIN;

UPDATE t1 SET c3=c3+1 WHERE c1 = 1; //阻塞住

Session 1:

COMMIT;

Session 2:

COMMIT;

但是考虑如下序列：

Session 1:

BEGIN;

INSERT INTO t1 VALUES (2,3,4);

Session 2:

UPDATE t1 SET c3=c3+1 WHERE c3 = 4; // 根据非索引列检索不阻塞，看不到记录(2,3,4)

Session 2:

UPDATE t1 SET c3=c3+1 WHERE c2 = 3; //但根据二级索引记录记录，被阻塞

我们知道Innodb的Insert操作本身并不创建行锁。在上述序列中Session2在更新记录时，发现记录对应的行记录的事务是活跃的，因此为Session 1构建了一个锁对象（lock_rec_convert_impl_to_expl）

实际上上述Session 2执行了隐式锁转显式锁，以及自身的LOCK_WAIT都创建了，为什么不会被阻塞呢？

在READ-COMMIT隔离级别下，Session 2 为Session 1创建的锁模式为

type_mode=1059 = 1024+32+3 = LOCK_REC_NOT_GAP | LOCK_REC | LOCK_X

随后Session 2自己加锁入等待队列：

type_mode=1283 = 1024 + 256 + 3 = LOCK_REC_NOT_GAP | LOCK_WAIT | LOCK_X

尽管创建了等待锁对象，但实际上返回上层函数时，会另做处理。

以下是从代码中摘录的（MySQL 5.7.5）:

row0sel.cc:

5124 err = sel_set_rec_lock(pcur,

5125 rec, index, offsets,

5126 prebuilt->select_lock_type,

5127 lock_type, thr, &mtr);

5128

5129 switch (err) {

……

……

5142 case DB_LOCK_WAIT:

5143 /* Lock wait for R-tree should already

5144 be handled in sel_set_rtr_rec_lock() */

5145 ut_ad(!dict_index_is_spatial(index));

5146 /* Never unlock rows that were part of a conflict. */

5147 prebuilt->new_rec_locks = 0;

5148

5149 if (UNIV_LIKELY(prebuilt->row_read_type

5150 != ROW_READ_TRY_SEMI_CONSISTENT)

5151 || unique_search

5152 || index != clust_index) {

5153

5154 goto lock_wait_or_error;

5155 }

5156

5157 /* The following call returns ‘offsets’

5158 associated with ‘old_vers’ */

5159 row_sel_build_committed_vers_for_mysql(

5160 clust_index, prebuilt, rec,

5161 &offsets, &heap, &old_vers, &mtr);

5162

5163 /* Check whether it was a deadlock or not, if not

5164 a deadlock and the transaction had to wait then

5165 release the lock it is waiting on. */

5166

5167 err = lock_trx_handle_wait(trx);

显然，满足以下三个条件的任意一个是，都会被阻塞住：

1、prebuilt->row_read_type != ROW_READ_TRY_SEMI_CONSISTENT //以上三例都是1，都不满足

2、unique_search //检索元组具有唯一性

3、index != clust_index //当前检索记录使用的索引不是聚集索引

当使用非索引列检索时，三者皆不满足；

当使用二级索引列检索时，满足index != clust_index

当使用聚集索引列检索时，满足unique_search

如果无需goto lock_wait_or_error，就会去构建对应记录的最老版本(row_sel_build_committed_vers_for_mysql)，对于插入而言，显然最老版本就是NULL空指针了，因此如果根据非索引列检索，Session 2就好像看不到那条记录一样，直接返回了。

如果表上没有索引的话，那么对于任意插入的记录，更新操作都见不到插入的记录（但是会为插入操作创建记录锁）。

我们再来看另外一种情况：

SESSION 1:

CREATE TABLE t1 (c1 int primary key , c2 int, c3 int, key(c2));

INSERT INTO t1 VALUES (1,2,3);

BEGIN;

UPDATE t1 SET c3 = c3 +1 WHERE c1 = 1; // c3 from 3=>4

UPDATE t1 SET c3 = c3 +1 WHERE c1 = 1; // c3 from 4=>5

SESSION 2:

UPDATE t1 SET c3=c3+1 WHERE c3 = 4; // No block

UPDATE t1 SET c3=c3+1 WHERE c3 = 5; // No block

UPDATE t1 SET c3=c3+1 WHERE c3 = 3; //阻塞住

实际上我们通过semi consistent read 能读到最老版本的记录时会将prebuilt->row_read_type从ROW_READ_TRY_SEMI_CONSISTENT修改成ROW_READ_DID_SEMI_CONSISTENT。

当读完记录后，返回Server层，会判断是否进行了semi consistent read。如果该记录符合查询，并且进行了semi consistent read，那么就再读该记录，第二次再读时，如果SESSION1还没提交，就会进入锁等待，被阻塞住。如果记录不符合查询，那么就直接忽略掉。

在上述的3条SQL中，第一条和第二条构建的最老版本记录，都不满足c3=4 和c3=5，因此忽略掉，不阻塞。但是最老记录满足c3 =3 ，因此在第二次进入innodb层时被阻塞住。

相关代码(sql_update.cc, mysql_update函数)

684 while (!(error=info.read_record(&info)) && !thd->killed)

685 {

686 thd->inc_examined_row_count(1);

687 bool skip_record= FALSE;

688 if (qep_tab.skip_record(thd, &skip_record))

689 {

690 error= 1;

691 /*

692 Don’t try unlocking the row if skip_record reported an error since

693 in this case the transaction might have been rolled back already.

694 */

695 break;

696 }

697 if (!skip_record)

698 {

699 if (table->file->was_semi_consistent_read())

700 continue; /* repeat the read of the same row if it still exists */

一个Innodb 事务可见性问题

浏览过的版块