作者介绍

“哥们，又双叒叕写了个死锁，秀啊！”

就算是经常写死锁的同学看到估计都会有点懵，两条一模一样的 DELETE 语句怎么会产生死锁呢？

看到这里的靓仔肯定对 MySQL 的锁非常了解，哥们还是带大家对锁的分类进行快速回顾；

要查看 MySQL 的加锁信息，必须启用 InnoDB 状态监控功能；

SET GLOBAL innodb_status_output=ON;SET GLOBAL innodb_status_output_locks=ON;

要获取 InnoDB 存储引擎的详细状态信息，可以使用以下 SQL 命令；

SHOW ENGINE INNODB STATUS;

在深入分析问题原因之前先对 DELETE 操作的基本流程进行复习。众所周知，MySQL 以页作为数据的基本存储单位，每个页内包含两个主要的链表：正常记录链表和垃圾链表。每条记录都有一个记录头，记录头中包括一个关键属性——deleted_flag。

执行 DELETE 操作期间，系统首先将正常记录的记录头中的 delete_flag 标记设置为 1。这一步骤也被称为 delete mark，是数据删除流程的一部分。

在事务成功提交之后，由 purge 线程 负责对已标记为删除的数据执行逻辑删除操作。这一过程包括将记录从正常记录链表中移除，并将它们添加到垃圾链表中，以便后续的清理工作。

针对不同状态下的记录，MySQL 在加锁时采取不同的策略，特别是在处理唯一索引上记录的加锁情况。以下是具体的加锁规则：

在分析死锁的案例中，我们关注的表 t_order_extra_item_15 具有一个由 (order_id, extra_key) 组成的联合唯一索引。为了更好地理解死锁的产生机制，我们将对上述死锁日志进行简化处理。

事务 A 试图获取记录锁，但被事务 B 持有的相同的记录锁所阻塞。而且，事务 B 在尝试获取临键锁时也遇到了阻塞，这是因为事务 A 先前已经请求了记录锁，从而形成了一种相互等待的状态，这种情况最终导致了死锁的发生。

然而事务 B 为何在已经持有记录锁的情况下还需要等待临键锁？唯一合理的解释是，在事务 B 最初执行 DELETE 操作时，它所尝试操作的记录已经被其他事务锁定。当这个其他事务完成了 delete mark 并提交后，事务 B 不得不重新发起对临键锁的请求。

经过深入分析得出结论，在并发环境中，必然存在另一个执行相同 DELETE 操作的事务，我们称之为事务 C。

通过仔细分析业务代码和服务日志，我们迅速验证了这一假设。现在，导致死锁的具体原因已经非常明显。为了帮助大家更好地理解三个事务的执行顺序，我们制定了一个事务执行时序的设想表格。

在执行流程的第 6 步中，事务 B 尝试重新获取临键锁，这时与事务 A 发生了相互等待的状况，导致死锁的发生。为解决这一问题，数据库管理系统自动回滚了事务 A，以打破死锁状态。

哥们深知道理论分析至关重要，实践才是检验真理的唯一标准。Talk is cheap, Show me the code. 在相同的系统环境下，我们创建了一个测试表来模拟实际情况；

CREATE TABLE `t_lock` (  `id` int NOT NULL,  `uniq` int NOT NULL,  `idx` int NOT NULL,  PRIMARY KEY (`id`),  UNIQUE KEY `uniq` (`uniq`) USING BTREE,  KEY `idx` (`idx`));
INSERT INTO t_lock VALUES (1, 1, 1);INSERT INTO t_lock VALUES (5, 5, 5);INSERT INTO t_lock VALUES (10, 10, 10);

大聪明一上来便直接手动开启 3 个 MySQL 命令列界面，每个界面中独立开启事务执行 DELETE FROM t_lock where uniq = 5; 语句，然而实验结果并未能成功复现先前讨论的死锁状况。

经过反复 SHOW ENGINE INNODB STATUS; 检查锁的状态得出结论：在 DELETE 操作中，加锁和 delete mark 是连续的不可分割的步骤，不受人为干预。一旦一个事务开始执行 DELETE，其他事务对该记录的访问请求将自动转为临键锁，避免了死锁的发生。

为了更准确地模拟并发环境下 DELETE 操作可能导致的死锁，这里采用 Java 语言编写了一个示例程序；

public class Main {
    private static final String URL = "jdbc:mysql://localhost:3306/db_test";    private static final String USER = "root";    private static final String PASSWORD = "123456";    private static final String SQL = "DELETE FROM t_lock WHERE uniq = 5;";
    public static void main(String[] args) {        // 开启 3 个线程，模拟并发删除        for (int i = 0; i < 3; i++) {            new Thread(Main::executeSQL).start();        }    }
    public static void executeSQL() {        try (                Connection connection = DriverManager.getConnection(URL, USER, PASSWORD);                Statement statement = connection.createStatement()        ) {            System.out.println(LocalTime.now() + ":" + Thread.currentThread().getName());            // 关闭自动提交            connection.setAutoCommit(false);            int rows = statement.executeUpdate(SQL);            // 延时 5 秒便于观察加锁信息            Thread.sleep(5000);            connection.commit();            System.out.println(LocalTime.now() + ":" + Thread.currentThread().getName() + ":" + rows);        } catch (Exception e) {            // 死锁堆栈输出            e.printStackTrace();        }    }}

果不其然，程序执行异常，异常堆栈中清晰地记录了死锁信息。进一步检查 MySQL 服务端的死锁日志，与线上业务的死锁日志如出一辙。程序执行过程中三个并发事务的加锁信息，和文章第四段的原因分析完全一致。这证实了我们的现场模拟成功复现了死锁情况。

不行。SELECT FOR UPDATE 的加锁逻辑与 DELETE 语句的加锁逻辑是一致的。加锁的类型完全取决于被加锁记录的状态。由于这一机制，使用 SELECT FOR UPDATE 并不能解决由 DELETE 操作引起的死锁问题。

的确，只有唯一索引会引发此类死锁问题，主键索引和普通索引均不会。在上述的系统环境下的实验结果表明，不同索引类型在索引等值加 X 锁情况下的行为如下：

唯一索引在处理"正常记录"时施加的是记录锁，但在处理处于"delete mark"状态的记录时，它施加的是临键锁。这种加锁类型的不一致性，在执行并发的 DELETE 操作时，增加了导致死锁的风险。

因为在同一行记录上过去已经有事务在等待获取锁了，为了避免锁饥饿现象的发生，先前请求加锁的事务在锁释放后将获得优先权。口说无凭，大聪明直接开启 2 个 MySQL 命令列界面，分别执行 DELETE FROM t_lock where uniq = 5; 语句，实际操作结果如下：

在操作流程的第四步中，事务 A 尝试请求对 uniq = 5 的临键锁，发现事务 B 已经先行一步请求了同一行记录上的临键锁。然而，事务 B 的这一请求由于事务 A 持有的记录锁而被阻塞，从而相互等待造成了死锁现象。

在 MySQL 环境 8.x 版本环境中，DELETE 操作引发的死锁情况得到了改进。通过观察加锁日志发现，事务在对于 delete mark 的记录加锁时，如果已经持有了该记录的记录锁，他将获取间隙锁而不是临键锁，这一变化有效避免了死锁的发生。

具体的加锁信息在此略去，大伙们若感兴趣可以亲自进行验证。

问题的来龙去脉都已梳理清晰，解决方案可归纳为以下几种：

平日朗诵八股文时如涛涛江水连绵不绝，可实际业务场景总会遇到各种奇葩的问题。因此，我们应该始终对技术保持一颗敬畏之心，追求不断学习和成长。

Stay hungry, stay Foolish. 

• [1]InnoDB Locking: https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html

• [2]An InnoDB Deadlock Example: https://dev.mysql.com/doc/refman/5.7/en/innodb-deadlock-example.html