MySQL 8.0死锁报错增多不是检测变严，而是默认开启innodb_deadlock_detect=ON，将原被5.7静默忽略的环形等待全部主动检测并中止；关掉该参数只会让问题更隐蔽，应优先通过加锁顺序一致、索引优化、SKIP LOCKED等手段规避触发条件。
MySQL 8.0 的死锁检测不是“需要优化”的功能，而是必须理解其行为并针对性规避触发条件；盲目调参（如关掉 innodb_deadlock_detect）只会让问题更隐蔽、更难定位。
为什么升级后死锁报错变多了？
这不是检测变“严”了，而是 8.0 默认开启 innodb_deadlock_detect=ON，把原来被静默忽略的环形等待全暴露出来。5.7 常被手动关掉，所以你之前没看到错误，不代表没发生——只是等满 innodb_lock_wait_timeout（默认 50 秒）才超时回滚，线程卡住、连接堆积、监控失灵。
- 查
SHOW ENGINE INNODB STATUS\G中LATEST DETECTED DEADLOCK时间戳是否密集、间隔稳定：如果是，说明检测在持续工作，不是误报 - 对比升级前后
information_schema.INNODB_TRX中长期未提交事务数：若明显增多，说明有长事务拖慢锁释放，不是检测本身的问题 - 别只看错误日志里“Deadlock found”，先确认是不是同一组表 + 同一索引反复出现在
HELD LOCKS和WAITING FOR THIS LOCK TO BE GRANTED中——这是加锁顺序不一致的铁证
真正降低死锁检测开销的方法
检测开销来自“事务尝试加锁失败 + 等待队列中已有其他等待者”这个路径被频繁进入。所以目标不是让检测更快，而是让它根本不用启动。
-
SELECT ... FOR UPDATE SKIP LOCKED：跳过已被锁定的行，各事务操作不同记录，无等待、无图、无检测 - 批量更新前对 ID 参数强制排序，比如
WHERE id IN (3,1,2)改成WHERE id IN (1,2,3) ORDER BY id，避免 ORM 自动生成 SQL 时顺序混乱 - 热点行更新改用应用层原子操作（如 Redis 计数器）或乐观锁（
version字段），绕过 InnoDB 行锁争抢 - 确认
innodb_autoinc_lock_mode = 2：批量插入不再持表级 AUTO-INC 锁，消除一大类锁等待源头
哪些参数真值得调？
innodb_deadlock_detect 不该关，innodb_sync_array_size 才是少数可调且有依据的选项。
- 当
performance_schema.data_locks中某个 hash bucket 锁数量 > 200，说明锁哈希分片不均，单个 mutex 成为热点，拖慢等待图刷新 - 逐步调大
innodb_sync_array_size（如从默认 16 → 32 → 64），需重启生效 - 调大后观察
innodb_mutex_spin_waits是否下降；若不降反升，说明分片过度，调度开销已盖过收益 -
innodb_print_all_deadlocks = ON必须开，否则死锁现场无法捕获；但注意它会持续刷盘，RDS 实例还需额外配置才能输出完整堆栈
最容易被忽略的是：MySQL 8.0 的 sys.innodb_lock_waits 视图底层依赖 performance_schema.data_lock_waits，读取时会申请 MDL 锁——这意味着你在排查时执行这个查询，本身可能被阻塞。真要查实时阻塞关系，优先用 SELECT * FROM performance_schema.data_lock_waits，并确保 events_transactions_current consumer 已启用。
