MySQL死锁需定位预防而非修复核心是用EXPLAIN分析type、key、rows三列以识别全表扫描、索引失效和预估偏差确保UPDATE/DELETE走覆盖索引事务中读写操作统一加锁并避免跨表依赖。死锁不是能“解决”的而是要定位预防MySQL死锁无法靠单条命令修复它本质是事务竞争资源时的循环等待。你看到的 Deadlock found when trying to get lock 错误只是系统主动杀掉其中一个事务的结果。真正要做的是用 EXPLAIN 看清 SQL 实际怎么走索引、是否触发锁升级、有没有扫描全表——这些才是死锁温床。EXPLAIN 要重点看这三列type、key、rows很多同学只扫一眼 EXPLAIN 输出就以为“用了索引”其实关键在细节type 是 ALL 或 index说明走了全表或全索引扫描锁住的行远超预期极易引发死锁key 显示的是哪个索引如果为 NULL或者用了非唯一索引但 WHERE 条件不精确比如模糊匹配、函数包裹字段就会锁住多个间隙gap lockrows 值是否远大于实际命中数比如 rows10000 但只更新 1 行说明优化器预估严重偏差很可能因统计信息过期或隐式类型转换导致示例EXPLAIN SELECT * FROM orders WHERE status pending AND user_id 123; 如果 type 是 ref 但 key 是 idx_status仅含 status 的索引那即使 user_id 有索引也会锁住所有 statuspending 的行——并发更新不同用户订单时就容易形成 A 等 B、B 等 A 的局面。UPDATE/DELETE 必须走覆盖索引否则死锁概率飙升MySQL 在执行 UPDATE 或 DELETE 时如果不能仅靠索引完成条件判断和数据定位就会先加记录锁record lock再加间隙锁gap lock最后可能升级成临键锁next-key lock。一旦涉及多行顺序稍有不同死锁就来了。 幻导航网 发现优质实用网站,开启网络探索之旅