事务死锁是MySQL中常见的并发问题，尤其在高并发写操作场景下容易发生。解决死锁的关键不在于完全避免（因为难以彻底消除），而在于合理设计和优化，使死锁发生概率降低，并能快速恢复。以下是几个实用的优化策略。
1. 理解死锁成因
死锁通常发生在两个或多个事务相互等待对方持有的锁。例如：
事务A持有行锁1，请求行锁2 事务B持有行锁2，请求行锁1此时MySQL会自动检测到死锁，选择一个代价较小的事务进行回滚，另一个继续执行。虽然系统能自动处理，但频繁死锁会影响性能和用户体验。
2. 按固定顺序访问表和行
保证所有事务以相同的顺序修改数据，可以极大减少死锁概率。
建议： 在应用层约定更新多张表时的顺序，比如先更新用户表，再更新订单表 更新同一张表的多行时，按主键排序后再执行UPDATE，避免加锁顺序混乱3. 缩小事务范围，加快执行速度
长时间运行的事务持有锁的时间更长，增加冲突机会。
做法： 避免在事务中执行耗时操作，如网络请求、复杂计算 只在必要时才开启事务，尽量做到“短事务” 及时提交或回滚，不要手动延迟COMMIT4. 合理使用索引，避免锁升级
没有索引时，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执行路径
基本上就这些。关键是在设计阶段就考虑并发控制，而不是等问题出现再补救。死锁无法根除，但通过规范编码和合理设计，可以把影响降到最低。
