MySQL死锁原因分析与解决方案详解

InnoDB锁机制与死锁基础

MySQL支持表级锁、页级锁和行级锁三种粒度。其中，表级锁开销小但并发度低且不会产生死锁；行级锁并发度高，但在复杂的事务交互中容易出现死锁。InnoDB作为目前最常用的支持事务的存储引擎，其默认的锁机制（包括共享锁、排他锁以及Next-Key Lock组合）是分析死锁问题的核心依据。

死锁的核心定义与成因

什么是死锁

死锁是指两个或两个以上的进程在执行过程中，因争夺资源而造成的一种互相等待的现象。若无外力作用（如强制回滚其中一个事务），它们都将无法推进下去。在MySQL中，解决死锁的关键在于打破循环等待条件，核心思路是让不同的Session对资源的加锁保持有序。

常见死锁场景分析

在实际开发中，以下几种模式极易触发死锁：

1. 随机分配导致的加锁顺序冲突

场景：业务逻辑需要将资金随机分配给多个借款人，并更新其余额。

问题演示：假设有两个用户A和B同时投资。用户A先锁借款人ID 1，再锁ID 2；而用户B由于随机性，可能先锁ID 2，再锁ID 1。此时，A等待B释放ID 2，B等待A释放ID 1，形成闭环等待，导致死锁。

解决方案：避免逐条锁定。将所有需要更新的记录ID在一次查询中锁定，利用MySQL的默认排序规则（按主键递增）保证加锁顺序一致：

SELECT * FROM borrower WHERE id IN (id_1, id_2) FOR UPDATE;

即使传入的ID顺序混乱，InnoDB也会自动按主键ID从小到大进行加锁。当两个事务都试图锁定相同的一组ID时，第二个事务会阻塞等待第一个事务完成，从而避免死锁。

2. GAP锁引发的插入冲突

场景：经典的“存在则更新，不存在则插入”逻辑（Upsert）。基于主键查询某行是否存在的判断分支。

原理：对于已存在的行，MySQL仅施加行锁（Record Lock）。但对于未存在的行（即便查询条件包含主键），InnoDB会施加间隙锁（Gap Lock）以封锁该范围内的插入操作。

冲突示例：若表中当前最大主键为12。事务1查询不存在的ID=22，可能获得(12, +∞)的间隙锁；事务2查询不存在的ID=23，也可能获得类似范围的间隙锁。两者互不兼容，后续执行插入时便会发生冲突或死锁。

解决方案：直接使用MySQL特有的语法替代判断逻辑：

INSERT INTO table_name (col1, col2) VALUES (val1, val2)
ON DUPLICATE KEY UPDATE col2 = val2;

此语句无论记录是否存在，都只申请行级别的锁，从根本上避免了Gap锁带来的不确定性。

3. 常规的单次加锁反向访问

场景：两个Session分别持有一把锁，然后尝试获取对方持有的另一把锁。

原理：这是最典型的死锁模型。Session A持有行1的锁，请求行2的锁；Session B持有行2的锁，请求行1的锁。如所示，双方均无法继续推进。

解决策略：全局统一加锁顺序（例如所有事务必须优先加锁ID较小的记录），或在应用层实现重试机制，捕获`Deadlock found`异常后重新提交事务。

总结

MySQL死锁并非不可控的灾难，而是并发控制机制下的特定表现。开发者应重点关注：
1. 尽量使用一次性批量加锁，并利用索引排序特性保持一致性。
2. 慎用非唯一索引或范围查询，防止误触Gap Lock。
3. 遵循统一的资源访问顺序，减少循环等待的概率。
4. 针对特定的查改逻辑，善用`INSERT ... ON DUPLICATE KEY UPDATE`简化并发冲突处理。

以上就是MySQL死锁产生原因及解决的详细内容，更多关于MySQL死锁排查的资料请关注本站其它相关文章！