死锁无法根除，但可通过优化降低发生率。1. 理解死锁成因：多事务相互等待对方持有的锁，MySQL自动回滚代价小的事务。2. 按固定顺序访问表和行：统一更新顺序，如先用户表后订单表，按主键排序更新避免加锁混乱。3. 缩小事务范围：避免长事务，减少锁持有时间，仅在必要时开启事务并及时提交。4. 合理使用索引：确保WHERE字段有索引，减少扫描与间隙锁，用EXPLAIN检查执行计划。5. 使用低隔离级别或乐观锁：业务允许时用READ COMMITTED减少间隙锁，冲突少时用版本号实现乐观锁。6. 捕获并重试死锁异常：捕获错误码1213，自动重试2~3次并加随机延迟防重试风暴。7. 监控与分析死锁日志：通过SHOW ENGINE INNODB STATUS查看最新死锁信息，结合慢查询日志优化SQL路径。设计阶段应提前考虑并发控制，规范编码以最小化影响。
事务死锁是MySQL中常见的并发问题，尤其在高并发写操作场景下容易发生。解决死锁的关键不在于完全避免（因为难以彻底消除），而在于合理设计和优化，使死锁发生概率降低，并能快速恢复。以下是几个实用的优化策略。
1. 理解死锁成因
死锁通常发生在两个或多个事务相互等待对方持有的锁。例如：
- 事务A持有行锁1，请求行锁2
- 事务B持有行锁2，请求行锁1
此时MySQL会自动检测到死锁，选择一个代价较小的事务进行回滚，另一个继续执行。虽然系统能自动处理，但频繁死锁会影响性能和用户体验。
2. 按固定顺序访问表和行
保证所有事务以相同的顺序修改数据，可以极大减少死锁概率。
建议：- 在应用层约定更新多张表时的顺序，比如先更新用户表，再更新订单表
- 更新同一张表的多行时，按主键排序后再执行UPDATE，避免加锁顺序混乱
3. 缩小事务范围，加快执行速度
长时间运行的事务持有锁的时间更长，增加冲突机会。
做法：- 避免在事务中执行耗时操作，如网络请求、复杂计算
- 只在必要时才开启事务，尽量做到“短事务”
- 及时提交或回滚，不要手动延迟COMMIT
4. 合理使用索引，避免锁升级
没有索引时，MySQL可能使用表级锁或锁定更多行，增加死锁风险。
注意：
- 确保WHERE条件中的字段有适当索引，减少扫描行数
- 避免全表扫描导致的间隙锁（gap lock）大面积覆盖
- 使用
EXPLAIN检查执行计划，确认走索引
5. 使用低隔离级别或乐观锁
高隔离级别（如可重复读）更容易产生锁。
考虑：- 如果业务允许，使用READ COMMITTED减少间隙锁使用
- 对于冲突较少的场景，采用乐观锁（版本号或时间戳）替代悲观锁
6. 捕获并重试死锁异常
应用程序应把死锁视为可恢复错误。
实现方式：- 捕获MySQL错误码1213（Deadlock found when trying to get lock）
- 自动重试事务，一般2~3次即可
- 加入随机延迟避免重试风暴
7. 监控与分析死锁日志
通过日志定位高频死锁场景。
操作方法：- 启用InnoDB死锁日志：
SHOW ENGINE INNODB STATUS\G - 查看LATEST DETECTED DEADLOCK部分，分析涉及的SQL、事务顺序
- 结合慢查询日志和业务逻辑优化SQL执行路径
基本上就这些。关键是在设计阶段就考虑并发控制，而不是等问题出现再补救。死锁无法根除，但通过规范编码和合理设计，可以把影响降到最低。
