MySQL高并发死锁本质是事务循环等待锁，可通过统一加锁顺序、缩短事务时间、合理设计索引、主动检测重试等措施大幅降低概率。
MySQL在高并发场景下出现死锁，本质是多个事务相互等待对方持有的锁，形成循环等待。死锁无法完全避免，但可通过设计和操作规范大幅降低发生概率。关键在于减少锁冲突、缩短事务时间、统一加锁顺序。
按固定顺序访问表和行
死锁常见于事务以不同顺序更新同一组数据。例如：事务A先更新user表再更新order表，事务B却先更新order再更新user，就容易触发死锁。
- 所有业务逻辑中，对多表的DML操作（尤其是UPDATE/DELETE）必须约定统一的执行顺序，如“先操作基础信息表（user/category），再操作业务单据表（order/payment）”
- 对单表多行更新，尽量按主键升序或唯一索引字段排序后再处理，可用ORDER BY id显式控制
- 批量更新时避免使用IN (a,b,c)无序列表，改用临时表+JOIN或按主键分批处理
缩小事务粒度，及时提交
长事务持有锁时间越长，与其他事务冲突窗口越大。尤其要避免在事务中嵌入网络调用、文件读写或用户交互。
- 只把真正需要原子性保障的操作放进事务，如“扣库存+生成订单”必须同事务，“发短信通知”应移出事务异步处理
- 避免在事务内执行耗时SQL（如大表COUNT、无索引JOIN），必要时拆分为预查+事务内精准操作
- 使用SET autocommit=1确保非必要时不开启隐式事务；显式事务务必配对使用BEGIN和COMMIT/ROLLBACK
合理设计索引，减少锁范围
缺少合适索引会导致MySQL升级为表锁或锁住过多无关行，显著增加死锁风险。
- UPDATE/DELETE语句必须走索引，否则会触发全表扫描+行锁升级为间隙锁甚至表锁；用EXPLAIN确认执行计划是否命中索引
- 高频更新字段建议单独建索引，联合索引需遵循最左匹配原则，避免因索引失效导致锁扩大
- 避免在WHERE条件中对索引字段使用函数或类型隐式转换（如WHERE DATE(create_time) = '2024-01-01'）
主动检测与优雅降级
即使做了充分预防，生产环境仍可能偶发死锁。应用层需具备识别和重试能力，而非直接报错中断。
- 捕获MySQL错误码1213（Deadlock found when trying to get lock），对可重试操作（如下单、抢购）做指数退避重试（最多2~3次）
- 记录死锁日志：SHOW ENGINE INNODB STATUS\G中的LATEST DETECTED DEADLOCK段落，定期分析高频死锁路径
- 监控Innodb_row_lock_waits和Innodb_deadlocks状态变量，设置告警阈值
