MySQL 8.0 并不会更容易产生死锁，而是通过持续死锁检测、更精确的间隙锁、更严格的MDL锁及完善的performance_schema监控，使原有隐蔽死锁问题显性化、快速暴露。
MySQL 8.0 在高并发下**并不会更容易产生死锁**，它只是让死锁更“显性”、更“快被发现”——你看到的“死锁变多”，其实是原本在 5.7 里被掩盖或延迟暴露的问题浮出水面了。
死锁检测从“按需触发”变成“持续追踪”
5.7 的死锁检测是被动的：只有当某个事务等锁超时（默认 50 秒），InnoDB 才启动一次全图遍历。大量短事务卡在锁队列里，只要没超时，就不会触发检测，也就不会报错、不会回滚，表现为“慢查询”或“卡住”。
8.0 默认开启 innodb_deadlock_detect=ON，后台线程持续维护等待图（wait-for graph），一旦成环，毫秒级就回滚一个事务并记录日志。
结果就是：同样一批并发请求，在 5.7 里可能只报 1 次死锁、其余卡住；在 8.0 里可能报出 5 次死锁——不是锁更多了，是“漏网之鱼”少了。
间隙锁行为更精确，冲突暴露更直接
5.7 的间隙锁（Gap Lock）常因优化器估算偏差而“合并”或“模糊覆盖”，比如对非唯一索引范围加锁时，可能只建一个大范围锁，表面看锁少，实则漏判冲突；
8.0 改用区间树（interval tree）管理 gap 范围，并把 gap 锁和插入意向锁（LOCK_INSERT_INTENTION）分离存储，导致：
- 同一 SELECT ... FOR UPDATE 操作，在 8.0 中可能生成多个独立 gap 锁对象（每个对应 disjoint 区间）
- 监控视图
performance_schema.data_locks里看到的锁数量上升，但这是“更真实”的反映 - 两个事务原本在 5.7 里因锁合并而侥幸没撞上，在 8.0 里因边界清晰反而立刻冲突
MDL 锁升级更严格，阻塞点前移
8.0 对元数据锁（MDL）做了语义强化：DDL 操作必须获取 MDL_EXCLUSIVE，且不允许被低优先级 DML “插队”。这本身不引发死锁，但会改变阻塞链条：
- 以前 ALTER TABLE 可能卡几十秒后突然抢到锁，期间 DML 还能跑；现在它一发起就立即申请强锁，若此时有长事务正持有
MDL_SHARED（比如未提交的 SELECT），就会立刻阻塞 - 如果这个长事务又反过来等某行锁，而那行锁又被另一个 DDL 等着，就容易形成跨层级死锁（MDL + 行锁）
- 这类组合型死锁在 5.7 里极难复现，8.0 下因锁语义收紧而变得可观察
performance_schema 让锁等待无处藏身
5.7 几乎只能靠 SHOW ENGINE INNODB STATUS 碰运气截取瞬时快照，INNODB_LOCK_WAITS 视图也不稳定；
8.0 的 performance_schema.data_locks 和 data_lock_waits 是实时、可 JOIN 的表结构，只要你开了相关 consumers，就能查到谁在等谁、等了多久、持有什么锁。
这意味着：以前你根本不知道存在锁等待，现在不仅知道，还能写脚本自动告警——所谓“死锁变多”，有时只是“终于看见了”。
真正该警惕的，不是“为什么 8.0 死锁多”，而是“为什么我的业务逻辑在 5.7 里能蒙混过关”：比如不同事务更新同一张表却用了不同索引顺序、批量更新和单行更新并发、缺失索引导致锁扩大……这些根因在 8.0 下会被更严苛的锁机制直接打出来。
