减少 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 IN (1,3,5) - 业务层批量操作前先对 ID 列排序，再拼接 SQL 或使用 ORDER BY 子句
- 避免混合使用不同索引路径访问同一张表（如一个事务走 name 索引，另一个走 age 索引更新重叠行）
合理设计索引与隔离级别
不合适的索引会导致锁范围扩大；过高的隔离级别会加剧锁竞争：
- 确保 WHERE 条件能命中最左前缀的高效索引，避免全表扫描导致锁住过多无关行
- 少用 SELECT ... FOR UPDATE，优先考虑应用层校验 + 唯一约束 + 普通 UPDATE，失败后重试
- 非强一致性场景可将隔离级别从 REPEATABLE READ 降为 READ COMMITTED（InnoDB 下后者不启用间隙锁，显著减少锁冲突）
- 确认业务是否真需要可重复读，很多支付/订单类场景其实只需读已提交
监控与主动规避
靠日志和指标提前发现隐患，比等线上报错更有效：
