MySQL 8.0死锁报错增多并非变脆弱，而是默认开启innodb_deadlock_detect后主动暴露原有隐性死锁；根本原因多为应用层锁序混乱、长事务未提交或间隙锁范围大，需优先排查SQL执行顺序与事务边界。
不是 MySQL 8.0 变得“更容易死锁”，而是它终于把原来被静默吞掉的死锁全报出来了——innodb_deadlock_detect 在 5.7 里常被手动关掉，而 8.0 默认 ON。先别急着改配置，真问题大概率在应用层。
查最近一次死锁现场用 SHOW ENGINE INNODB STATUS\G
这是最直接、最不可替代的手段。它返回的是最后一次死锁的完整上下文，关键看 LATEST DETECTED DEADLOCK 段：
- 确认两个（或多个）事务各自执行的 SQL，尤其注意
UPDATE/DELETE的 WHERE 条件是否一致、顺序是否错位 - 比对
HELD LOCKS和WAITING FOR THIS LOCK TO BE GRANTED：如果事务 A 持有table_a却等table_b，事务 B 持有table_b却等table_a，就是典型锁序混乱 - 注意
trx_id和thread id，可结合information_schema.INNODB_TRX查该事务的开始时间、运行时长，判断是否为长事务残留
别信 sys.innodb_lock_waits 的实时性
MySQL 8.0 中这个视图底层依赖 performance_schema.data_locks，读取时会主动申请 MDL 锁。一旦有 DDL（如 ALTER TABLE）正在执行，查询就会卡在 Waiting for table metadata lock，导致监控脚本阻塞、连接池积压、锁等待时间拉长——你看到的“死锁变多”，可能是监控本身拖垮了系统。
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 排查时优先用
performance_schema.data_lock_waits替代sys.innodb_lock_waits - 检查是否有未完成的 DDL：
SELECT * FROM performance_schema.metadata_locks WHERE OBJECT_TYPE = 'TABLE' AND LOCK_STATUS = 'PENDING'; - 避免在业务高峰期执行 DDL；若必须执行，考虑用
pt-online-schema-change等无锁工具
重点盯住三类高危 SQL 模式
升级后暴露的死锁，90% 都集中在以下场景，不是引擎变了，是旧逻辑在更严格的检测下现形：
-
SELECT ... FOR UPDATE后没及时COMMIT或ROLLBACK：查information_schema.INNODB_TRX中trx_started时间异常早的记录 - 批量
UPDATE ... WHERE id IN (1,2,3,...,1000)但id列没走索引：触发全表扫描+大范围间隙锁，多个事务同时扫同一区间极易形成循环等待 - 应用层重试逻辑无退避：死锁报错后立刻重试，又撞上同样锁竞争，形成
Deadlock → retry → Deadlock循环；应加指数退避和最大重试次数限制
真正难处理的不是死锁本身，而是那些跨服务、跨数据库、带外部调用的长事务——它们让锁持有时间不可控，也让锁序无法统一收敛。这类问题没法靠 DBA 调参解决，得从分布式事务边界和业务流程拆分入手。
