死锁是多个事务相互等待资源导致的僵局，MySQL通过自动回滚一个事务来解决；可通过固定顺序访问数据、缩短事务长度等方法降低发生概率，并在应用层捕获错误码1213后重试以应对。
死锁是数据库并发操作中的一种异常状态，理解它对优化 MySQL 性能和避免程序卡顿非常重要。简单来说，死锁是指两个或多个事务相互等待对方释放资源，导致谁也无法继续执行的情况。
死锁是如何发生的？
在 MySQL 的 InnoDB 存储引擎中，行级锁机制允许高并发操作，但也可能引发死锁。以下是一个典型场景：
- 事务 A 持有 row1 的锁，请求 row2 的锁
- 事务 B 持有 row2 的锁，请求 row1 的锁
这时，A 等 B 释放 row2，B 等 A 释放 row1，形成循环等待，死锁产生。
MySQL 如何处理死锁？
InnoDB 会自动检测死锁，并选择一个“牺牲者”事务进行回滚，以打破循环。被回滚的事务会收到错误码 1213 (Deadlock found when trying to get lock)，另一个事务则可以继续执行。
你可以通过以下方式查看最近一次死锁信息：
DESTOON B2B网站管理系统
下载
DESTOON B2B网站管理系统是一套完善的B2B(电子商务)行业门户解决方案。系统基于PHP+MySQL开发，采用B/S架构，模板与程序分离，源码开放。模型化的开发思路，可扩展或删除任何功能；创新的缓存技术与数据库设计，可负载千万级别数据容量及访问。
输出中的 LATEST DETECTED DEADLOCK 部分会详细展示发生死锁的时间、涉及的事务、SQL 语句、持有的锁和等待的锁。
如何减少死锁的发生？
虽然无法完全避免，但可以通过良好设计显著降低概率：
- 按固定顺序访问表和行：如果所有事务都先更新用户表再更新订单表，就能避免交叉加锁
- 缩短事务长度：尽快提交事务，减少持锁时间
- 避免在事务中做用户交互：比如等用户输入时还持有锁，极易引发问题
- 批量操作尽量合并：分批提交比大事务更容易出现锁竞争
- 合理使用索引：没有索引可能导致全表扫描，加更多不必要的锁
应用层该如何应对？
程序中应捕获死锁异常（错误码 1213），并实现重试逻辑：
- 记录日志以便分析高频死锁点
- 等待短暂时间后重试事务
- 限制重试次数，防止无限循环
基本上就这些。死锁不是系统错误，而是并发控制的正常现象。关键是设计合理的事务流程，并做好异常处理。理解它，就能更好地驾驭 MySQL 的并发能力。
