MySQL如何实现并发控制？（下）｜内有彩蛋

页级别的并发访问控制主要通过 index 和 page 上的锁来实现，其实也就是 B+tree 的加锁过程。在介绍加锁过程前，先结合数据看一下 B+tree 的访问路径。

事实上，B+tree 的加锁过程其实也是按照上述访问路径进行的。还是以上述的查询为例，B+tree 上加锁的过程如下图所示：

类似的，如果是页上的乐观更新（或者是页内的插入），那么 B+tree 上加锁的过程如下图所示：

InnDB 在执行数据更新操作时，会首先尝试使用乐观更新（MODIFY LEAF），如果乐观更新失败，那么会进入到悲观更新（MODIFY TREE）的逻辑，悲观更新的加锁过程如下图所示：

在介绍行级别的并发访问控制前，先一起看一个有意思的问题：

为了搞清楚这个问题，笔者关闭 MySQL 上的死锁检查逻辑（innodb_deadlock_detect设置为 OFF），然后再次尝试了上述的操作。结果发现，session 2 和 session 3 确实卡住了，结果前面提到的 performance_schema 下的 data_locks 表进行查看：

通过 data_locks 表中的锁等待关系发现，session 2（THREAD_ID = 69）和 session 3（THREAD_ID = 70）都在等待意向锁，隐含的语义是都持有了 Gap 锁，所以造成了死锁。

所以，通过上面的例子可以知道，即使是 RC 隔离级别下简单的主键插入，也并不只是对单行记录加锁，并且还可能造成死锁。

行锁的基本概念

1. 记录锁（Rec Lock），即对单行记录上加的锁，官方代码中的名字是 LOCK_REC_NOT_GAP；从加锁类型上来说，记录锁优又可以分为记录读锁（S 锁）和记录写锁（X）锁；

2. 间隙锁（Gap Lock），对行记录的间隙加的锁，官方代码中的名字是 LOCK_GAP；（补充一句，网上有很多文章都说 Gap 锁是为了解决 RR （REPEATABLE-READ，可重复读）隔离级别写的幻读问题，其实并不完全是，前面的插入死锁的例子也能说明。关于事务隔离级别的问题，不是本文讨论的重点，这里不再展开。）

3. 下键锁（Next-Key Lock），可以简单的理解就是记录锁和间隙锁的组合（记录前的间隙），官方代码中的名字是 LOCK_ORDINARY；

在进入案例分析前，还是以一个写入过程为例，结合代码进行一个主要逻辑的说明，主要的代码堆栈如下：

|--> ha_innobase::write_row
|    |--> row_insert_for_mysql
|    |    |--> row_insert_for_mysql_using_ins_graph
|    |    |    |--> // run_again
|    |    |    |--> row_ins_step
|    |    |    |    |--> row_ins
|    |    |    |    |    |--> row_ins_index_entry_step
|    |    |    |    |    |    |--> row_ins_index_entry
|    |    |    |    |    |    |    |--> row_ins_clust_index_entry // 插入主键
|    |    |    |    |    |    |    |    |--> row_ins_clust_index_entry_low
|    |    |    |    |    |    |    |
|    |    |    |    |    |    |    |--> row_ins_sec_index_entry // 插入二级索引
|    |    |    |
|    |    |    |--> row_mysql_handle_errors
|    |    |    |    |--> lock_wait_suspend_thread // 锁等待，唤醒后进入 run_again


|--> row_ins_clust_index_entry_low
|    |--> btr_pcur_t::open  // 遍历 b+tree
|    |
|    |--> row_ins_duplicate_error_in_clust // 第一次插入不会进入（隐式锁）
|    |    |--> row_ins_set_rec_lock
|    |    |    |--> lock_clust_rec_read_check_and_lock
|    |    |    |    |--> lock_rec_convert_impl_to_expl // 隐式锁转显式锁
|    |    |    |    |    |--> lock_rec_convert_impl_to_expl_for_trx
|    |    |    |    |    |    |--> lock_rec_add_to_queue
|    |    |    |    |    |    |    |--> rec_lock.create // RecLock::create
|    |    |    |    |    |    |    |    |--> lock_alloc
|    |    |    |    |    |    |    |    |--> lock_add
|    |    |    |    |    |    |    |    |    |--> // 不等待
|    |    |    |    |    |    |    |    |    |--> lock_rec_insert_to_granted
|    |    |    |    |    |    |    |    |    |--> locksys::add_to_trx_locks
|    |    |    |    |--> lock_rec_lock // 构造锁等待
|    |    |    |    |    |--> lock_rec_lock_fast
|    |    |    |    |    |    |--> rec_lock.create // RecLock::create
|    |    |    |    |    |--> lock_rec_lock_slow
|    |    |    |    |    |    |--> lock_rec_has_expl
|    |    |    |    |    |    |--> lock_rec_other_has_conflicting // 检查冲突
|    |    |    |    |    |    |--> rec_lock.add_to_waitq
|    |    |    |    |    |    |    |--> create // RecLock::create
|    |    |    |    |    |    |    |    |--> lock_alloc
|    |    |    |    |    |    |    |    |--> lock_add
|    |    |    |    |    |    |    |    |    |--> // 等待
|    |    |    |    |    |    |    |    |    |--> lock_rec_insert_to_waiting
|    |    |    |    |    |    |    |    |    |--> locksys::add_to_trx_locks
|    |    |    |    |    |    |    |    |    |--> lock_set_lock_and_trx_wait
|    |
|    |--> btr_cur_optimistic_insert // 乐观插入
|    |    |--> btr_cur_ins_lock_and_undo
|    |    |    |--> lock_rec_insert_check_and_lock // 插入前的锁冲突检查
|    |    |    |    |--> lock_rec_other_has_conflicting
|    |    |    |    |--> rec_lock.add_to_waitq
|    |    |    |--> trx_undo_report_row_operation
|    |--> btr_cur_pessimistic_insert // 悲观插入

从上述代码来看，最开始的例子中的插入过程应该是这样的：

2、session 2 进行插入时，在 row_ins_duplicate_error_in_clust函数中进行冲突检查时：

关于写入过程中的加锁过程，上面只是借助 insert 导致死锁的案例进行了一个非常简单的介绍，重点还是说清楚插入过程中行锁的产生以及锁等待产生的基本逻辑，InnoDB 行锁的内容非常丰富，此处不再继续展开，后面有时间可以单独再进行介绍。

DROP TABLE IF EXISTS `t1`;

CREATE TABLE `t1` (
`id` int NOT NULL AUTO_INCREMENT,
`a` int DEFAULT NULL,
`b` int DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `uk_a` (`a`)
) ENGINE=InnoDB;

INSERT INTO t1 values (1, 10, 0);
INSERT INTO t1 values (2, 20, 0);
INSERT INTO t1 values (3, 30, 0);
INSERT INTO t1 values (4, 40, 0);
INSERT INTO t1 values (5, 50, 0);

注：需关闭 MySQL 上的死锁检查逻辑（innodb_deadlock_detect设置为 OFF）。