mysql的死锁是指两个或两个以上的事务在执行过程中，因争夺锁资源而造成的一种互相等待的现象，若无外力作用，这些事务将无法继续推进。死锁会导致部分事务回滚，影响业务的正常执行，因此需要掌握对应的排查方法。
死锁产生的常见原因
在排查死锁之前，需要先了解死锁产生的常见场景，方便后续定位问题：
- 事务按照不同的顺序获取行锁，比如事务A先锁id=1的行再锁id=2的行，事务B先锁id=2的行再锁id=1的行，就容易产生死锁
- 事务执行时间过长，持有锁的时间太久，增加了和其他事务冲突的概率
- 索引使用不当，导致锁的范围扩大，比如没有走索引导致行锁升级为表锁，或者范围锁覆盖了太多不需要的行
- 隔离级别设置不合理，比如可重复读隔离级别下，间隙锁的使用可能增加锁冲突的概率
通过系统变量查看最近的死锁信息
mysql的InnoDB引擎提供了innodb_print_all_deadlocks系统变量，开启后可以将所有死锁信息记录到错误日志中，同时也可以通过SHOW ENGINE INNODB STATUS命令查看最近一次死锁的详细信息。
开启死锁信息记录
可以通过以下命令动态开启死锁信息记录，重启后会失效，如果需要永久生效需要修改配置文件：
-- 查看当前innodb_print_all_deadlocks变量的值 SHOW VARIABLES LIKE 'innodb_print_all_deadlocks'; -- 开启死锁信息记录到错误日志 SET GLOBAL innodb_print_all_deadlocks = ON;
查看最近一次死锁详情
执行下面的命令可以获取InnoDB引擎的状态信息，其中包含最近一次死锁的详细内容：
SHOW ENGINE INNODB STATUSG
在返回的结果中，找到LATEST DETECTED DEADLOCK部分，里面会记录死锁发生的时间、参与死锁的事务信息、每个事务持有的锁和等待的锁、最终回滚的事务等内容，通过分析这些信息可以确定死锁的触发逻辑。
通过系统表查询事务和锁信息
mysql提供了information_schema库下的系统表，可以实时查询当前运行的事务和锁的持有情况，适合在死锁发生时实时排查。
查询当前运行的事务
通过INNODB_TRX表可以查看当前正在运行的所有InnoDB事务：
SELECT
trx_id, -- 事务ID
trx_state, -- 事务状态，如RUNNING、LOCK WAIT等
trx_started, -- 事务开始时间
trx_mysql_thread_id, -- 事务对应的mysql线程ID
trx_query, -- 事务正在执行的SQL语句
trx_tables_in_use, -- 事务使用的表数量
trx_tables_locked -- 事务锁定的表数量
FROM information_schema.INNODB_TRX;
查询锁的持有和等待情况
通过INNODB_LOCKS表可以查看当前所有的锁信息，INNODB_LOCK_WAITS表可以查看锁的等待关系：
-- 查看当前所有的锁
SELECT
lock_id, -- 锁ID
lock_trx_id, -- 持有锁的事务ID
lock_mode, -- 锁模式，如X、S、GAP等
lock_type, -- 锁类型，如RECORD、TABLE
lock_table, -- 锁对应的表
lock_index, -- 锁对应的索引
lock_data -- 锁对应的数据
FROM information_schema.INNODB_LOCKS;
-- 查看锁等待关系
SELECT
requesting_trx_id, -- 请求锁的事务ID
requested_lock_id, -- 请求的锁ID
blocking_trx_id, -- 阻塞的事务ID
blocking_lock_id -- 阻塞的锁ID
FROM information_schema.INNODB_LOCK_WAITS;
结合以上两个查询结果，可以关联到具体的事务和执行的SQL，快速定位死锁相关的SQL语句。
通过错误日志排查历史死锁
如果已经开启了innodb_print_all_deadlocks变量，所有的死锁信息都会被记录到mysql的错误日志中，错误日志的默认路径可以通过SHOW VARIABLES LIKE 'log_error';命令查看。
可以直接在错误日志中搜索deadlock关键字，找到对应的死锁记录，分析每次死锁的触发场景，总结规律进行优化。
死锁排查步骤总结
当业务反馈出现死锁问题时，可以按照以下步骤进行排查：
- 先查看最近的死锁信息，执行
SHOW ENGINE INNODB STATUSG获取最新的死锁详情，确定参与死锁的事务和SQL - 如果问题已经复现，可以查询
INNODB_TRX、INNODB_LOCKS、INNODB_LOCK_WAITS三个系统表，获取实时的锁和事务信息 - 查看错误日志中的历史死锁记录，确认是否是重复出现的死锁场景
- 根据获取到的SQL语句，分析事务的执行顺序、索引使用情况，确定死锁产生的根因
减少死锁的优化建议
排查到死锁根因后，可以通过以下方式减少死锁的发生：
- 尽量让事务按照相同的顺序获取锁，避免交叉加锁
- 缩小事务的范围，减少事务的执行时间，尽早提交或回滚事务
- 合理设计索引，避免锁范围过大，尽量使用行锁而不是表锁
- 如果业务允许，可以适当降低事务隔离级别，比如从可重复读调整为读已提交，减少间隙锁的使用
- 在代码中捕获死锁异常，进行重试操作，降低死锁对业务的影响
示例：模拟死锁并排查
下面通过一个简单的示例模拟死锁场景，然后演示排查过程。
创建测试表和数据
-- 创建测试表
CREATE TABLE test_deadlock (
id INT PRIMARY KEY,
num INT
) ENGINE=InnoDB;
-- 插入测试数据
INSERT INTO test_deadlock VALUES (1, 100), (2, 200);
模拟死锁的两个事务
打开两个mysql客户端，分别执行以下事务：
客户端1执行：
-- 事务1：先更新id=1的行 BEGIN; UPDATE test_deadlock SET num = num + 1 WHERE id = 1;
客户端2执行：
-- 事务2：先更新id=2的行 BEGIN; UPDATE test_deadlock SET num = num + 1 WHERE id = 2;
再回到客户端1执行：
-- 事务1尝试更新id=2的行，此时会等待事务2释放锁 UPDATE test_deadlock SET num = num + 1 WHERE id = 2;
再回到客户端2执行：
-- 事务2尝试更新id=1的行，此时会触发死锁，mysql会回滚其中一个事务 UPDATE test_deadlock SET num = num + 1 WHERE id = 1;
排查模拟的死锁
死锁发生后，执行SHOW ENGINE INNODB STATUSG，在LATEST DETECTED DEADLOCK部分可以看到两个事务的ID、持有的锁、等待的锁，以及最终回滚的事务，和我们在客户端执行的操作完全对应，由此可以确定死锁是因为两个事务交叉更新不同行导致的。