减少 MySQL 死锁需降低资源争抢强度与时长：缩短事务执行时间、按主键升序访问多行、优化索引与隔离级别、加强监控及热点分段更新。

减少 MySQL 死锁，核心在于降低事务对资源的争抢强度和时长，而不是完全避免——死锁在高并发下无法彻底消除，但可大幅降低发生概率。

缩短事务执行时间

长事务会持有锁更久，增加与其他事务交叉等待的概率。应尽量让事务“快进快出”：

• 避免在事务内做耗时操作（如 HTTP 调用、复杂计算、大文件读写）
• 提前准备好所有数据，减少事务中 SQL 的数量
• 批量更新尽量用单条 INSERT ... ON DUPLICATE KEY UPDATE 或 REPLACE INTO 替代多条语句
• 查询尽量加覆盖索引，避免事务中触发回表或临时表

按固定顺序访问资源

死锁常因两个事务以相反顺序更新同一组行（如事务 A 先改 id=1 再改 id=5，事务 B 反过来）。统一访问顺序可切断循环等待链：

• 更新多行时，始终按主键升序（或唯一索引字段）排序后再执行，例如：
  UPDATE t SET status=1 WHERE id IN (5,1,3) → 改为 WHERE id I

  

  N (1,3,5)
• 业务层批量操作前先对 ID 列排序，再拼接 SQL 或使用 ORDER BY 子句
• 避免混合使用不同索引路径访问同一张表（如一个事务走 name 索引，另一个走 age 索引更新重叠行）

合理设计索引与隔离级别

不合适的索引会导致锁范围扩大；过高的隔离级别会加剧锁竞争：

• 确保 WHERE 条件能命中最左前缀的高效索引，避免全表扫描导致锁住过多无关行
• 少用 SELECT ... FOR UPDATE，优先考虑应用层校验 + 唯一约束 + 普通 UPDATE，失败后重试
• 非强一致性场景可将隔离级别从 REPEATABLE READ 降为 READ COMMITTED（InnoDB 下后者不启用间隙锁，显著减少锁冲突）
• 确认业务是否真需要可重复读，很多支付/订单类场景其实只需读已提交

监控与主动规避

靠日志和指标提前发现隐患，比等线上报错更有效：

• 开启 innodb_print_all_deadlocks = ON，把死锁信息输出到 error log，定期分析高频冲突表和 SQL 模式
• 监控 Innodb_row_lock_waits 和 Innodb_row_lock_time_avg，数值突增说明锁竞争加剧
• 对热点行（如账户余额、库存计数器）采用“分段更新”策略（如把 total_stock 拆成 stock_shard_0 ~ stock_shard_9），分散锁竞争
• 关键更新接口加入轻量重试逻辑（如捕获 Deadlock found when trying to get lock 后延迟 10–100ms 重试 1–2 次）