细说 MySQL 死锁（1）准备工作

死锁检查线程，检查并解决死锁，分为三步走，这期先聊聊准备工作：构造锁等待图、初始化事务权重。

> 作者：操盛春，爱可生技术专家，公众号『一树一溪』作者，专注于研究 MySQL 和 OceanBase 源码。 > >爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。

> 本文基于 MySQL 8.0.32 源码，存储引擎为 InnoDB。

1. 模拟死锁

创建测试表：

CREATE TABLE `t1` ( `id` int unsigned NOT NULL AUTO_INCREMENT, `i1` int DEFAULT '0', PRIMARY KEY (`id`) USING BTREE, KEY `idx_i1` (`i1`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3; 

插入测试数据：

INSERT INTO `t1` (`id`, `i1`) VALUES (10, 101), (20, 201), (30, 301), (40, 401); 

创建 4 个连接，按以下顺序执行示例 SQL：

-- 连接 1（事务 1） BEGIN; SELECT id FROM t1 WHERE id = 10 FOR UPDATE; -- 连接 2（事务 2） BEGIN; SELECT id FROM t1 WHERE id = 20 FOR UPDATE; -- 连接 3（事务 3） BEGIN; SELECT i1 FROM t1 WHERE id = 10 FOR UPDATE; -- 连接 4（事务 4） BEGIN; SELECT id, i1 FROM t1 WHERE id = 10 FOR UPDATE; -- 连接 1（事务 1） SELECT i1 FROM t1 WHERE id = 20 FOR UPDATE; -- 连接 2（事务 2） SELECT * FROM t1 WHERE id = 10 FOR UPDATE; 

每个连接启动一个事务，分别为事务 1 ~ 4。按照各事务进入锁等待状态的顺序，等待关系如下：

• 事务 3 等待事务 1 释放 <id = 10> 的行锁。
• 事务 4 等待事务 1 释放 <id = 10> 的行锁。
• 事务 1 等待事务 2 释放 <id = 20> 的行锁。
• 事务 2 等待事务 1 释放 <id = 10> 的行锁。

2. 死锁检查线程

InnoDB 有个名为 ib_srv_lock_to 的后台线程，每秒进行一次超时检查，看看是否有锁等待超时的事务。

这个线程是个多面手，除了检查并处理锁等待超时，还会检查并解决死锁。

前面介绍锁等待超时，我们把这个线程称为超时检查线程，这里我们又把它称为死锁检查线程，大家知道这是同一个线程就好了。

死锁检查线程会监听一个锁等待事件，这个事件的超时时间为 1 秒。

每次开始监听之后的 1 秒内：

• 如果没有事务从运行状态进入锁等待状态，监听结束，进行一轮死锁检查。
• 如果某个事务加锁发生等待，会发送通知，死锁检查线程收到通知之后，立即结束监听，进行一轮死锁检查。

每一轮死锁检查，如果发现了死锁，则解决死锁。检查并解决死锁之后，继续监听锁等待事件。死锁检查线程就这么不断重复着等待、检查死锁、解决死锁的循环。

3. 锁等待快照

事务加锁发生等待，给死锁检查线程发送通知之前，都会在锁模块的 waiting_threads 属性指向的内存区域中找到一个空闲的 slot，把加锁信息保存到这个 slot 中。

> 每个 slot 存放的都是 srv_slot_t 对象，加锁信息实际上是保存到 srv_slot_t 对象中。

死锁检查线程，要做的第一件事，就是把此刻处于锁等待状态的那些事务记下来，也就是构造锁等待快照，这需要遍历 waiting_threads 属性指向的内存区域。

遍历过程从 waiting_threads 属性指向的内存区域中第一个 slot 开始，到 last_slot 属性指向的 slot 前面的 slot（已被使用的最后一个 slot）为止。

每次取一个 slot，如果这个 slot 已被某个锁等待事务使用，就构造一个 waiting_trx_info_t 对象，追加到快照数组里。

> 为了方便介绍，我们把 waiting_trx_info_t 对象称为快照对象。

快照对象有 4 个属性：锁等待事务、阻塞事务、srv_slot_t 对象、版本号（MySQL 本次启动以来发生的锁等待次数，包含这次锁等待在内）。

以示例 SQL 中第 1 个发生锁等待的事务 3 为例，它对应的快照对象如下：

{ 事务 3, /* 锁等待事务 */ 事务 1, /* 阻塞事务 */ srv_slot_t 0, /* 第 1 个 slot 里面 * 保存的 srv_slot_t 对象 */ 4 /* 版本号 */ } 

示例 SQL 中，4 个事务都发生了锁等待，构造出来的快照数组里有 4 个快照对象：

/* 快照数组 */ /* 0 */ { 事务 3, 事务 1, srv_slot_t 0, 4 } /* 1 */ { 事务 4, 事务 1, srv_slot_t 1, 5 } /* 2 */ { 事务 1, 事务 2, srv_slot_t 2, 6 } /* 3 */ { 事务 2, 事务 1, srv_slot_t 3, 7 } 

4. 锁等待图

有了快照数组，就有了构造锁等待图的基础。

不过，这个快照数组还不能直接使用，需要进一步处理，就是按照事务对象的内存地址从小到大进行排序。

以示例 SQL 的快照数组为例，排序之后，就变成下面这样了：

/* 排序之后的快照数组 */ /* 0 */ { 事务 1, 事务 2, srv_slot_t 2, 6 } /* 1 */ { 事务 2, 事务 1, srv_slot_t 3, 7 } /* 2 */ { 事务 3, 事务 1, srv_slot_t 0, 4 } /* 3 */ { 事务 4, 事务 1, srv_slot_t 1, 5 } 

接下来就可以基于排序之后的快照数组构造锁等待图了。

> 为了方便介绍，后面提到的快照数组，都是排序之后的快照数组。

锁等待图，表示快照数组中各个快照对象的锁等待事务之间的等待关系。

有一点需要说明，存放等待关系使用的数据结构并不是图，而是数组，我们称之为锁等待数组。

构造锁等待图，需要遍历快照数组。 遍历过程中，每次取一个快照对象（X），找到以其中的阻塞事务作为锁等待事务的快照对象（Y）。

然后，构造两个快照对象的锁等待事务之间的等待关系：

• 用快照对象 X 在快照数组中的下标，作为锁等待数组的下标，找到锁等待数组中对应的数组单元。
• 用快照对象 Y 在快照数组中的下标，作为上一步的数组单元值。

为了更好理解，我们以遍历示例 SQL 的快照数组为例，第 1 轮循环取第 1 个快照对象。

第 1 步，第 1 个快照对象（X）中的阻塞事务为事务 2，找到以它作为锁等待事务的第 2 个快照对象（Y）。

第 2 步，第 1 个快照对象在快照数组中的下标 0，作为锁等待数组的下标，找到对应的数组单元。

第 3 步，第 2 个快照对象在快照数组中的下标 1，作为上一步的数组单元值。

经过以上步骤，锁等待数组中第 1 个单元（下标为 0）的值就变成了 1，表示事务 1 等待事务 2。

遍历快照数组结束之后，就得到了锁等待数组，还是以示例 SQL 为例，得到以下锁等待数组：

/* 锁等待数组 */ [ 0: 1, /* 事务 1 等待事务 2 */ 1: 0, /* 事务 2 等待事务 1 */ 2: 0, /* 事务 3 等待事务 1 */ 3: 0 /* 事务 4 等待事务 1 */ ] 

5. 事务权重

5.1 初始化权重

构造锁等待图之后，接下来会给快照数组中所有事务（也就是处于等待状态的事务）初始化权重。

如果多个事务等待获得同一条记录的行锁，或者同一个表的表锁，事务优化级相同的情况下，权重最高的事务会获得锁。

初始化事务权重，也需要遍历快照数组，遍历过程中，每次取一个快照对象。

对于每个快照对象，如果其中的锁等待事务满足某个条件，InnoDB 会把该事务的权重设置为一个比较大的值，否则该事务的权重设置为 1。

描述清楚需要满足的这个条件，得费点功夫，我们慢慢来。

假设快照数组中的锁等待事务数量为 N，也就是 InnoDB 中当前有 N 个事务在等待获得锁。

如果某个快照对象中的锁等待事务（X）进入锁等待状态之后，又有 2N 个事务进入过锁等待状态，那就需要提升事务 X 的权重。

为啥呢？

因为事务 X 进入锁等待状态之后，又有 2N 个事务进入过锁等待状态，而当前只有 N 个事务正处于锁等待状态，说明这 2N 个锁等待事务中，已经有 N 个事务获得了锁，而在它们前面的事务 X 竟然还没有获得锁，这是不是有点不公平？

确实不公平，事务 X 都要饿死了。

为了不让事务 X 饿死，InnoDB 会把它的权重设置为比较大的值，也就是提升它的权重，以提升它获得锁的优先程度。

那么，权重提升到多少呢？

这有一个计算公式：

min(N, 1e9 / N) 

用大白话解释上面的公式，就是取以下两个值中小的那个：

• 事务等待数量（N）。
• 1e9 / N（10 的 9 次方，除以事务等待数量）。

我们还是以示例 SQL 为例，初始化之后，各快照对象中的锁等待事务权重如下：

/* 权重数组 */ [ 0: 1, /* 事务 1 */ 1: 1, /* 事务 2 */ 2: 1, /* 事务 3 */ 3: 1 /* 事务 4 */ ] 

> 示例 SQL 的权重数组中，所有快照对象的锁等待事务权重都为 1，说明没有事务快要被饿死了。

5.2 提升权重

初始化快照数组中所有锁等待事务的权重之后，InnoDB 还要继续给部分锁等待事务提升权重。

哪些事务会再次被提升权重？

如果某些锁等待事务，阻塞了其它事务获得锁，也就是说，它们既是某个快照对象中的锁等待事务，又是其它一个或多个快照对象中的阻塞事务，它们就会再次被提升权重。

这里会怎么提升权重呢？

也很简单，就是把锁等待事务的权重累加到阻塞事务的权重上。

我们以示例 SQL 快照数组中的事务 1 为例，提升权重的过程，就是把被事务 1 阻塞的其它事务的权重，累加到事务 1 的权重上。

为了方便理解，我们把示例 SQL 的锁等待数组、权重数组放到这里：

/* 锁等待数组 */ [ 0: 1, /* 事务 1 等待事务 2 */ 1: 0, /* 事务 2 等待事务 1 */ 2: 0, /* 事务 3 等待事务 1 */ 3: 0 /* 事务 4 等待事务 1 */ ] /* 权重数组 */ [ 0: 1, /* 事务 1 */ 1: 1, /* 事务 2 */ 2: 1, /* 事务 3 */ 3: 1 /* 事务 4 */ ] 

通过锁等待数组可以看到，事务 1 阻塞了 3 个事务，分别为事务 2、3、4。

按照前面的介绍，事务 2、3、4 的权重都会累加到事务 1 的权重上。然而，这里只有事务 3、4 的权重会累加到事务 1 的权重上。

为啥呢？

因为事务 2 有点特殊，它和事务 1 相互等待，发生了死锁。

同样，虽然事务 2 阻塞了事务 1，但是事务 1 权重也不会累加到事务 2 的权重上。

发生死锁的那些事务，相互等待，它们之间的等待关系形成了一个环，想要把环中锁等待事务的权重累加到阻塞事务的权重上，不知道从哪里开始，到哪里结束。

所以，这里提升权重时，死锁环中锁等待事务的权重不会累加到阻塞事务的权重上。

等到解决死锁之后，还会再更新一次死锁环中各事务的权重。

通过以上权重数组可以看到，事务 1 ~ 4 的权重都为 1，事务 3、4 的权重累加到事务 1 的权重上，事务 1 的权重提升为 3 了。

这个步骤中，给阻塞事务提升完权重之后，示例 SQL 的权重数组变成下面这样了：

/* 权重数组 */ [ 0: 3, /* 事务 1 */ 1: 1, /* 事务 2 */ 2: 1, /* 事务 3 */ 3: 1 /* 事务 4 */ ] 

5.3 更新权重

经过初始化权重、提升权重两个步骤得到的各事务权重，都还保存在权重数组里，这些权重需要更新到各锁等待事务的事务对象中。

更新锁等待事务的权重时，会排除发生死锁的事务，因为这些事务的权重还没有最终计算完成。

6. 总结

死锁检查线程，每次检查是否发生死锁之前，都需要做一些准备工作：

• 构造锁等待快照，并按照快照对象中的锁等待事务对象的内存地址从小到大进行排序。
• 基于排序之后的快照数组，构造锁等待图。
• 基于锁等待图得到权重数组。
• 根据锁等待关系，进一步提升阻塞事务的权重。
• 把事务权重更新到各事务对象中。

更多技术文章，请访问：https://opensource.actionsky.com/

关于 SQLE

SQLE 是一款全方位的 SQL 质量管理平台，覆盖开发至生产环境的 SQL 审核和管理。支持主流的开源、商业、国产数据库，为开发和运维提供流程自动化能力，提升上线效率，提高数据质量。

✨ Github：https://github.com/actiontech/sqle

📚 文档：https://actiontech.github.io/sqle-docs/

💻 官网：https://opensource.actionsky.com/sqle/

👥 微信群：请添加小助手加入 ActionOpenSource

🔗 商业支持：https://www.actionsky.com/sqle</id></id></id></id>