事务死锁是MySQL中常见的并发问题，尤其在高并发写操作场景下容易发生。解决死锁的关键不在于完全避免（因为难以彻底消除），而在于合理设计和优化，使死锁发生概率降低，并能快速恢复。以下是几个实用的优化策略。

1. 理解死锁成因

死锁通常发生在两个或多个事务相互等待对方持有的锁。例如：

• 事务A持有行锁1，请求行锁2
• 事务B持有行锁2，请求行锁1

此时MySQL会自动检测到死锁，选择一个代价较小的事务进行回滚，另一个继续执行。虽然系统能自动处理，但频繁死锁会影响性能和用户体验。

2. 按固定顺序访问表和行

保证所有事务以相同的顺序修改数据，可以极大减少死锁概率。

建议：

• 在应用层约定更新多张表时的顺序，比如先更新用户表，再更新订单表
• 更新同一张表的多行时，按主键排序后再执行UPDATE，避免加锁顺序混乱

3. 缩小事务范围，加快执行速度

长时间运行的事务持有锁的时间更长，增加冲突机会。

做法：

• 避免在事务中执行耗时操作，如网络请求、复杂计算
• 只在必要时才开启事务，尽量做到“短事务”
• 及时提交或回滚，不要手动延迟COMMIT

4. 合理使用索引，避免锁升级

没有索引时，MySQL可能使用表级锁或锁定更多行，增加死锁风险。

如知AI笔记

如知笔记——支持markdown的在线笔记，支持ai智能写作、AI搜索，支持DeepseekR1满血大模型

27

查看详情

注意：

• 确保WHERE条件中的字段有适当索引，减少扫描行数
• 避免全表扫描导致的间隙锁（gap lock）大面积覆盖
• 使用EXPLAIN检查执行计划，确认走索引

5. 使用低隔离级别或乐观锁

高隔离级别（如可重复读）更容易产生锁。

考虑：

• 如果业务允许，使用READ COMMITTED减少间隙锁使用
• 对于冲突较少的场景，采用乐观锁（版本号或时间戳）替代悲观锁

6. 捕获并重试死锁异常

应用程序应把死锁视为可恢复错误。

实现方式：

• 捕获mysql错误码1213（Deadlock found when trying to get lock）
• 自动重试事务，一般2~3次即可
• 加入随机延迟避免重试风暴

7. 监控与分析死锁日志

通过日志定位高频死锁场景。

操作方法：

• 启用InnoDB死锁日志：SHOW ENGINE INNODB STATUSG
• 查看LATEST DETECTED DEADLOCK部分，分析涉及的SQL、事务顺序
• 结合慢查询日志和业务逻辑优化SQL执行路径

基本上就这些。关键是在设计阶段就考虑并发控制，而不是等问题出现再补救。死锁无法根除，但通过规范编码和合理设计，可以把影响降到最低。