MySQL 8.0死锁检测更激进、日志需额外开启innodb_print_all_deadlocks、锁监控须用performance_schema.data_lock_waits、间隙锁行为不变但可见性增强、MDL互斥更严格。
innodb_deadlock_detect 默认值没变，但行为更激进
MySQL 5.7 和 8.0 都默认开启 innodb_deadlock_detect（值为 ON），但 8.0 的死锁检测逻辑更频繁、路径更细粒度，尤其在高并发短事务场景下更容易触发检测并回滚。这不是参数开关变了，而是底层检测器实现升级了：它现在会扫描更多等待图分支，也更早介入等待链判断。
常见错误现象包括：
- 应用日志里突然出现更多
Deadlock found when trying to get lock错误，而业务逻辑未改动 - CPU 使用率在高峰期明显升高，
SHOW PROCESSLIST中大量线程处于updating或Locked状态
建议动作：
- 先确认当前状态：
SHOW VARIABLES LIKE 'innodb_deadlock_detect'; - 若确系误报多且负载极高（如每秒数千事务），可临时关掉：
SET GLOBAL innodb_deadlock_detect = OFF;，但必须配套应用层重试+超时兜底 - 关掉后，依赖
innodb_lock_wait_timeout（默认 50 秒）被动超时，响应延迟风险上升
死锁日志输出方式不同，排查入口变了
5.7 只有发生死锁时才写一条简略记录到 error log，且默认不开启全量记录；8.0 要想看到完整死锁信息，必须同时开两个参数：innodb_deadlock_detect = ON（检测开关）和 innodb_print_all_deadlocks = ON（日志开关）。否则即使死锁发生，error log 里也可能什么都没有。
使用场景：
- 线上刚升级完发现死锁频发，但 error log 查不到详情 → 检查是否漏设
innodb_print_all_deadlocks - RDS 实例还需额外设置
log_error_verbosity = 3才能输出死锁堆栈
注意：innodb_print_all_deadlocks 会持续写日志，生产环境建议只在问题定位期开启，问题解决后关闭。
performance_schema.data_lock_waits 是 8.0 唯一可靠的实时锁等待视图
5.7 用 INFORMATION_SCHEMA.INNODB_LOCKS 和 INNODB_LOCK_WAITS，但这两个表只在真实发生锁冲突时才非空，且 8.0 已废弃；8.0 必须用 performance_schema.data_lock_waits 查当前阻塞关系，配合 data_locks 看谁持有什么锁。
典型误操作：
- 沿用 5.7 脚本查
INNODB_LOCK_WAITS，返回空结果就认为“没锁等待”，其实只是视图不更新 - 没开
performance_schema或相关 consumers（如events_transactions_current），导致data_lock_waits始终为空
检查与启用步骤：
- 确认已启用：
SELECT * FROM performance_schema.setup_consumers WHERE NAME LIKE 'transactions%';，确保对应行的ENABLED为YES - 查实时阻塞：
SELECT * FROM performance_schema.data_lock_waits; - 结合
THREAD_ID关联performance_schema.threads查具体 SQL
间隙锁与临键锁行为一致，但监控粒度更透明
RR 隔离级别下，5.7 和 8.0 对 WHERE col = ?（有索引）都加 X,REC_NOT_GAP 行锁，对 WHERE col > ? 加 X,GAP 间隙锁，这点没变。真正区别在于：8.0 的 performance_schema.data_locks 能直接看到锁类型字段（LOCK_MODE），比如 X,REC_NOT_GAP 或 X,GAP，而 5.7 的 INNODB_LOCKS.LOCK_MODE 只显示 X，无法区分是行锁还是间隙锁。
这意味着：
- 升级后若发现间隙锁冲突变多，不是锁逻辑变了，而是原来看不见的问题现在暴露了
- 排查时别只盯着“有没有锁”，重点看
LOCK_MODE和LOCK_DATA，确认是否因缺失索引导致全表扫描，意外锁住大量 gap - 测试语句如
INSERT INTO t VALUES (7,7,7);在已有(5,5)和(10,10)时，会等(5,10)区间的 gap 锁，这个行为 5.7/8.0 一致，但 8.0 能一眼在data_locks里看到
最易被忽略的一点：8.0 的 MDL 增强让 DDL 和 DML 互斥更严格，有时你以为是死锁，其实是 session A 持着 MDL 读锁（比如一个长 SELECT），session B 的 ALTER TABLE 在等它，而 session C 的 UPDATE 又在等 session B —— 这种跨锁域的等待链，data_lock_waits 不会显示，得查 metadata_locks 表。
