mysql自动处理死锁，回滚并报错1213，开发者需捕获异常重试事务；通过SHOW ENGINE INNODB STATUS分析死锁原因；按序访问、缩短事务、用索引、避免等待和合理隔离可减少死锁；应用层应实现有限重试。
mysql 中死锁是多个事务相互等待对方释放锁，导致都无法继续执行的情况。MySQL 会自动检测到死锁，并选择一个事务进行回滚，以打破循环等待，让其他事务继续执行。这个过程是自动的，但作为开发者或 dba，你还需要了解如何应对和减少死锁的发生。
1. 理解 MySQL 死锁的自动处理机制
当 MySQL 检测到死锁时，会主动回滚其中一个事务，并抛出错误码 1213（Deadlock found when trying to get lock）。被回滚的事务需要由应用程序重新执行。
例如，你可能会看到这样的报错：
Error 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
这说明事务已被终止，你需要在应用层捕获该异常并重试事务。
2. 手动查看死锁信息
可以通过以下方式查看最近一次死锁的详细信息，帮助分析原因：
启用 InnoDB 状态监控：
SHOW ENGINE INNODB STATUSG
在输出结果中查找 LATEST DETECTED DEADLOCK 部分，这里会显示：
- 发生死锁的时间
- 两个或多个事务的等待图
- 每个事务持有的锁和请求的锁
- 涉及的 SQL 语句
这些信息对定位死锁根源非常关键。
3. 减少死锁发生的策略
虽然不能完全避免死锁，但可以通过优化设计显著降低概率：
- 按固定顺序访问表和行：确保所有事务以相同的顺序修改数据。例如，总是先更新用户表，再更新订单表，避免交叉加锁。
- 减少事务大小：尽量缩短事务执行时间，尽快提交事务，减少锁持有时间。
- 使用索引避免全表扫描：全表扫描可能引入大量不必要的间隙锁（gap lock），增加死锁风险。
- 避免在事务中等待用户输入：长时间挂起事务会延长锁持有时间。
- 合理使用隔离级别：如非必要，可使用 READ COMMITTED 替代 REPEATABLE READ，减少间隙锁的使用。
4. 应用层处理死锁
由于死锁无法完全避免，建议在应用程序中实现重试逻辑：
- 捕获死锁异常（如 MySQL 的 1213 错误）
- 等待短暂时间（如 100ms）
- 重新执行整个事务
通常重试 1-3 次即可成功，避免无限重试。
基本上就这些。MySQL 自己会解除死锁，重点在于如何分析原因并从设计上减少其发生频率。配合应用层的重试机制，系统就能稳定运行。不复杂但容易忽略。