如何减少死锁发生_mysql并发场景优化_网络技术

发布时间 - 2026-01-23 00:00:00 点击率：次

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

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

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

死锁常因两个事务以相反顺序更新同一组行（如事务 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 下后者不启用间隙锁，显著减少锁冲突）
确认业务是否真需要可重复读，很多支付/订单类场景其实只需读已提交

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

开启 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 次）