死锁是并发设计的必然副产品，无法彻底避免；应通过重试降级、顺序化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 之后的行（取决于执行计划）
真正棘手的是业务逻辑耦合导致的锁顺序混乱——这时需要重构事务边界，比如把“扣库存+生成订单”拆成异步消息，而不是塞进一个事务里硬扛。
