mysql并发更新频繁导致死锁怎么办_mysql死锁处理方案

死锁是并发设计的必然副产品，无法彻底避免；应通过重试降级、顺序化sql、索引优化、死锁日志持久化及事务拆分等手段快速暴露、低损恢复并定位根因。

死锁不是bug，是并发设计的必然副产品

mysql 死锁无法彻底避免，尤其在高并发更新同一张表、多个事务交叉更新多行（如 UPdate ... WHERE id IN (1,3,5)）或未按固定顺序加锁时。InnoDB 的行级锁 + 两阶段锁协议天然存在死锁风险。关键不是“怎么消灭死锁”，而是“怎么让死锁快速暴露、低损恢复、可定位根因”。

立刻生效的缓解措施：重试 + 降级 + 顺序化

应用层必须主动处理死锁异常，不能依赖数据库自动回滚后就终止流程：

• 捕获 MySQL 错误码 1213（Deadlock found when trying to get lock），对失败事务做指数退避重试（如 10ms → 30ms → 100ms），最多 3 次
• 避免在事务中调用外部服务（http/API），防止事务持锁时间不可控
• 所有涉及多行更新的语句，强制按主键升序排列条件，例如把 UPDATE t SET x=1 WHERE id IN (5,1,3) 改成 UPDATE t SET x=1 WHERE id IN (1,3,5) —— 这能大幅降低交叉加锁概率
• 高频更新场景考虑拆分热点行，比如用 shard_id 字段替代单条记录承担全部写压力

定位死锁根源：别只看 SHOW ENGINE INNODB STATUS

SHOW ENGINE INNODB STATUS 只显示最近一次死锁，且信息易被覆盖。生产环境必须开启死锁日志持久化：

SET GLOBAL innodb_print_all_deadlocks = ON;

该配置会将每次死锁详细信息（包括两个事务的 SQL、持有锁、等待锁、事务堆栈）写入 MySQL 错误日志。配合日志采集系统（如 Filebeat + ES），可快速聚合分析高频死锁模式。

常见根因示例：

• 事务 A 先更新 id=100 再更新 id=200；事务 B 反向操作 → 必死锁
• 无索引字段更新（如 UPDATE t SET status=1 WHERE name='abc'）触发全表扫描加锁，锁住大量无关行
• 长事务中执行 select ... for UPDATE 后迟迟不提交，把锁占着不动

ALTER table 不是万能解药，但索引能切掉80%死锁

90%以上的死锁源于锁粒度失控。检查 EXPLaiN 输出，确保所有 WHERE 条件走索引（尤其是 UPDATE/delete）：

• 复合查询条件（如 WHERE user_id=123 AND status='pending'）建联合索引，注意最左前缀匹配
• 避免在索引列上使用函数或隐式类型转换（如 WHERE DATE(create_time) = '2024-01-01' 会失效）
• 大表慎用 UPDATE ... LIMIT N，InnoDB 仍可能扫描并锁住 LIMIT 之后的行（取决于执行计划）

真正棘手的是业务逻辑耦合导致的锁顺序混乱——这时需要重构事务边界，比如把“扣库存+生成订单”拆成异步消息，而不是塞进一个事务里硬扛。