在 MySQL 中，死锁是一个常见但复杂的问题，特别是在并发事务较多的情况下。死锁如果处理不当，可能导致应用性能下降甚至服务不可用。因此，掌握 MySQL 的死锁排查方法对于 DBA 和开发者来说尤为重要。

本文将从死锁的概念出发，详述 MySQL 中死锁的常见原因，并提供一套系统的排查和解决流程，帮助你快速定位问题根源，优化数据库设计和操作方式。

一、什么是死锁？

在关系型数据库中，死锁是指多个事务因互相等待对方释放锁而陷入僵局的状态。每个事务都锁住了另一个事务需要的资源，而任何一个事务都无法继续执行下去。

例如，事务 A 持有资源 X 的锁并等待资源 Y，而同时事务 B 持有资源 Y 的锁并等待资源 X，这种循环等待的情况称为死锁。

MySQL 中通常会在检测到死锁时主动终止其中一个事务，释放其占用的资源，使另一个事务能够顺利执行。

二、死锁产生的常见原因

死锁的产生往往伴随着以下几种情况：

  1. 访问顺序不一致
    不同事务以不同的顺序访问相同的资源（表、行等），可能导致循环依赖。例如，事务 A 先锁住表 orders，后锁住表 customers，而事务 B 刚好反过来。

  2. 多个事务并发锁定相同的资源
    当多个事务试图同时对同一资源加不同类型的锁（例如共享锁、排他锁）时，如果某些锁的释放次序不当，就可能发生死锁。

  3. 事务过多或执行时间较长
    长时间运行的事务会占用锁更长的时间，这增加了其他事务进入死锁的风险。

  4. 索引失效导致的意外锁定
    当查询未能使用索引时，可能会对更多的数据行加锁，扩大锁的范围，增加死锁概率。

三、如何排查 MySQL 死锁？

1. 分析死锁日志

当 MySQL 检测到死锁时，会自动记录一个死锁信息，即 死锁日志。我们可以通过以下方式快速定位死锁原因：

（1）启用死锁日志

默认情况下，MySQL 会将死锁信息存储在 SHOW ENGINE INNODB STATUS 命令的输出中。通过以下命令查看：

SHOW ENGINE INNODB STATUS\G

命令执行后，输出结果中会包含类似以下的死锁信息：

------------------------
LATEST DETECTED DEADLOCK
------------------------
2023-10-18 15:23:56
*** (1) TRANSACTION:
TRANSACTION 124572 FE8A77, ACTIVE 5 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 5 lock struct(s), heap size 1136, 3 row lock(s)
MySQL thread id 8, OS thread handle 1407352192, query id 768 localhost inserting
INSERT INTO orders ...
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 5 page no 232 n bits 72 index PRIMARY of table `test`.`orders` trx id 124572 lock_mode X locks rec but not gap
...

（2）日志中的关键信息

死锁日志包含以下关键内容：

  • 涉及的事务：显示发生死锁的事务 ID。

  • 加锁的对象：如表名、索引、具体的锁类型（共享锁 S，排他锁 X 等）。

  • SQL 语句：引发死锁的具体 SQL。

  • 等待的资源：事务当前正在等待被释放的资源。

通过分析死锁日志中的这些信息，可以快速确定是哪些事务、哪些表或行，以及哪些 SQL 导致了死锁。

2. 使用 INFORMATION_SCHEMA 系统表排查

MySQL 提供了多个 INFORMATION_SCHEMA 表，用于查看锁定相关的信息。这些表对于排查潜在的死锁问题非常有用。

（1）查看当前锁信息

通过查询 INFORMATION_SCHEMA.INNODB_LOCKS 表，可以查看当前正在持有或等待的锁。

SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;

输出结果中的字段如：

  • LOCK_TYPE：锁的类型（记录锁、间隙锁等）。

  • LOCK_MODE：锁模式（S、X）。

  • LOCK_TRX_ID：持有该锁的事务 ID。

（2）查看事务依赖关系

INFORMATION_SCHEMA.INNODB_LOCK_WAITS 表记录了事务之间的依赖关系。例如，哪个事务正在等待另一个事务释放锁。

SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;

通过将 INNODB_LOCKS 和 INNODB_LOCK_WAITS 表连接起来，可以重现死锁的依赖图。

3. 捕获并分析执行计划

（1）检查是否使用了索引

有时死锁可能是由于全表扫描引起的行级锁竞争。执行以下命令查看 SQL 的执行计划：

EXPLAIN SELECT * FROM orders WHERE order_id = 123;

如果发现没有使用索引，应尽量优化 SQL 或为查询字段添加合适的索引。

（2）检查锁范围

对于 UPDATE 和 DELETE 类操作，执行计划可以帮助判断是否锁定了超出预期的行范围。例如，发现查询误使用了全表扫描，可调整 SQL 或更新索引。

四、解决与预防死锁的策略

1. 明确资源访问顺序

确保所有事务以相同的顺序访问表和行资源。例如，统一先访问表 customers 再访问表 orders，避免循环等待。

2. 减少大事务的持锁时间

将大事务拆分为更小的事务，确保每个事务尽量短小、快速地完成。

3. 使用合理的索引

索引能够限制锁定范围，避免因全表扫描而导致的广泛加锁。同时，定期检查索引是否失效。

4. 避免不必要的事务嵌套

事务嵌套可能导致复杂的锁依赖关系，增加死锁概率。在可能的情况下，简化事务逻辑。

5. 调整系统参数

在某些场景下，适当调整 MySQL 的锁超时参数（如 innodb_lock_wait_timeout）可以缓解死锁问题。

五、总结

MySQL 的死锁问题是并发环境下的常见难题，对其排查和优化需要技巧、细致分析和实践经验。通过分析死锁日志、使用系统表监控锁信息、优化 SQL 和事务设计，可以有效减少死锁的发生。

在实际的生产环境中，建议对数据库的设计提前进行规划，并结合应用的具体场景制定规范化的事务处理策略。只有这样，我们才能在高并发系统中应对死锁问题，从容应对数据库的挑战。