MySQL通过InnoDB的死锁检测机制自动处理事务死锁，发现环路时回滚牺牲者事务并返回错误1213；建议按顺序访问数据、缩短事务长度、避免交互操作、使用较低隔离级别和合理索引设计，应用层应捕获1213错误并实现幂等重试逻辑以保障系统稳定。

MySQL处理事务死锁主要依赖于其内置的死锁检测机制和自动回滚策略。当多个事务相互等待对方持有的锁时，就会发生死锁。MySQL通过InnoDB存储引擎自动识别这种情况，并采取措施打破僵局，确保系统可以继续运行。

死锁检测机制

InnoDB会定期运行死锁检测算法，分析事务之间的锁等待关系。它构建一个“等待图”（wait-for graph），如果发现图中存在环路，就说明出现了死锁。

一旦检测到死锁：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• MySQL会选择其中一个事务作为“牺牲者”，自动将其回滚
• 被回滚的事务会收到一个错误码 1213 (Deadlock found when trying to get lock)
• 另一个事务则能继续执行，获得所需锁资源

减少死锁发生的建议

虽然MySQL能自动处理死锁，但频繁死锁会影响性能和用户体验。可以通过以下方式降低发生概率：

• 按固定顺序访问表和行：所有事务以相同顺序加锁，避免交叉等待
• 缩短事务长度：尽快提交事务，减少持锁时间
• 避免用户交互在事务中：不要在事务提交前等待用户输入
• 使用较低隔离级别：如READ COMMITTED，在某些场景下可减少间隙锁使用
• 合理设计索引：避免全表扫描导致大量不必要的锁

应用层应对策略

由于死锁可能随时发生，应用程序应具备重试逻辑：

• 捕获死锁异常（错误号1213）
• 在应用代码中实现事务重试机制，通常重试2-3次即可
• 注意幂等性，确保重复执行不会造成数据不一致

基本上就这些。MySQL能自动解决死锁问题，关键在于合理设计事务逻辑并在应用层做好容错处理。不复杂但容易忽略。