MySQL 5.7死锁频发主因是锁管理器瓶颈、间隙锁粗放、死锁检测被动滞后；8.0通过精准间隙锁、主动等待图检测、自增锁与唯一键校验优化显著降低死锁率。
根本原因不是5.7“更差”，而是它的锁管理器在高并发插入时更容易成为瓶颈，加上间隙锁行为更难预测，导致死锁被频繁触发并暴露出来。
innodb_lock_wait_timeout 和死锁检测机制差异
MySQL 5.7 的死锁检测是被动触发的：只有当某个事务在 innodb_lock_wait_timeout（默认 50 秒）内拿不到锁，InnoDB 才启动一次全图遍历。这意味着很多等待链在真正闭环前就已堆积数秒甚至更久，一旦检测启动，往往已是多事务深度嵌套等待——死锁概率陡增。
MySQL 8.0 默认开启 innodb_deadlock_detect = ON，后台线程持续维护等待图，只要形成环就毫秒级回滚。虽然 CPU 开销略升，但避免了“等满 timeout 才动手”的滞后性，实际死锁发生率反而下降。
常见误操作：
- 沿用 5.7 脚本监控
SHOW ENGINE INNODB STATUS\G截取死锁日志，但在 8.0 下该输出结构已变，关键字段位置偏移，解析易失败 - 没开
innodb_print_all_deadlocks = ON，导致 error log 里死锁记录为空——5.7 默认不写全量，8.0 必须显式开启才记
间隙锁范围与 Insert Intention Lock 兼容性
5.7 在 RR 隔离级别下对间隙锁的加锁逻辑更“粗放”：非唯一索引范围扫描、空表 INSERT、甚至 INSERT ... ON DUPLICATE KEY UPDATE 都可能锁定比实际需要更大的区间。而 Insert Intention Lock 虽兼容间隙锁，但需排队获取——当多个事务同时向同一间隙插入，又无明确排序依据时，极易形成循环等待。
8.0 对间隙锁范围做了收敛优化，尤其在主键或唯一索引冲突场景下，锁定位更精准，不同事务间锁交集概率降低。
典型现象：
- 空表并发
INSERT INTO t (id) VALUES (1), (2)：5.7 中所有事务竞争 (-∞, +∞) 这个单一间隙，必现死锁；8.0 仍会锁间隙，但哈希分片和锁分配器改进让排队更有序，死锁频率明显下降 - 二级索引字段
UPDATE t SET x=1 WHERE status = 'pending'后紧跟INSERT：5.7 可能因扫描路径差异锁住不同子区间，造成交叉等待；8.0 的索引检查路径更稳定，间隙覆盖更一致
自增锁与唯一键校验路径叠加效应
5.7 默认 innodb_autoinc_lock_mode = 1，对不确定行数的 INSERT（如带子查询、ON DUPLICATE KEY）会升级为表级 AUTO-INC 锁，持续到语句结束。此时若恰有唯一键冲突检查正在申请 Insert Intention Lock，而该间隙又被另一个事务的 Next-Key Lock 占着——三重锁等待嵌套，死锁窗口被显著拉长。
8.0 改进了底层锁哈希结构和唯一键校验路径，减少了重复索引扫描次数，尤其在二级索引多、行存在率高的场景下，冲突检查更快完成，缩短了锁持有时间。
注意点：
-
innodb_autoinc_lock_mode = 2在 5.7 中要求binlog_format = ROW，否则主从 ID 不一致；8.0 对该组合的支持更健壮，但若业务仍用 MIXED 或 STATEMENT 格式，降级 lock mode 反而引入风险 - 外键约束检查在 5.7 中可能触发对引用表的全表扫描式加锁，8.0 优化了隐式锁检测，提前介入减少等待链长度
排查时最容易忽略的细节
死锁日志里看到 lock_mode X locks gap before rec 是 5.7 典型信号，说明问题出在间隙锁而非数据行本身；但很多人只盯着 WAITING FOR THIS LOCK TO BE GRANTED 那一行，却漏看上面的 HOLDS THE LOCK(S) ——那里藏着另一个事务已经持有的锁范围，才是冲突根源。
更隐蔽的是 MDL（元数据锁）干扰：5.7 中 DDL 操作可能“插队”抢锁，导致 INSERT 突然被阻塞几十秒后才报死锁；8.0 的 MDL 语义更严格，阻塞更早暴露，但排查时若只查 INNODB_LOCK_WAITS，会完全错过 MDL 等待——必须查 performance_schema.metadata_locks（5.7 不支持此表）。
