mysql 8.0通过将全局lock_sys->mutex拆分为rec_hash/prdt_hash分片锁、wait_mutex等多细粒度锁，缓解cpu核间争用；死锁检测改为持续追踪等待图，p99延迟降60%+；新增nowait/skip locked语法实现应用层主动锁控制。
因为 MySQL 8.0 把原来一把全局 lock_sys->mutex 拆成了多个细粒度锁，让热点行锁、死锁检测、哈希分片操作不再互相阻塞——高并发下 CPU 核之间不用再抢同一把锁空转。
为什么 5.7 在 32 核机器上锁争用严重
5.7 的锁管理器靠单个 lock_sys->mutex 串行保护所有操作：加行锁、释放锁、扫描等待图都得排队。在多核环境里，这导致大量 false sharing 和 spin-wait，SHOW ENGINE INNODB STATUS 中常看到 LOCK_grant 或 lock_sys->mutex 占 top 等待事件。你不是慢，是线程在等锁时反复刷新缓存行。
- 现象：QPS 随并发线程增加不升反降，
innodb_row_lock_waits暴涨 - 监控线索：
performance_schema.events_waits_summary_global_by_event_name中wait/synch/mutex/innodb/lock_sys_mutex时间占比异常高 - 根本瓶颈不在磁盘或网络，而在锁管理器自身成了单点
8.0 的 lock_sys 拆分到底拆了哪些锁
8.0 不是简单“加锁”，而是按职责解耦：不同模块用不同 mutex，互不干扰。
-
lock_sys->mutex：只管rec_hash和prdt_hash的元数据（如哈希表扩容） -
lock_sys->wait_mutex：专用于维护等待图（wait-for graph），死锁检测不再和行锁申请抢同一把锁 - 每个
rec_hash分片带独立锁：默认分片数由innodb_sync_array_size控制；若设为 1，则仍退化为单锁 - 热点行更新分散到不同哈希桶后，
lock_rec_lock()调用可并行执行
实测中，innodb_sync_array_size = 4（对应 16–32 核）能让 innodb_row_lock_time_avg 下降约 35%，前提是业务存在真实热点行（比如订单状态表主键更新）。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
NOWAIT / SKIP LOCKED 和死锁检测变化怎么影响应用行为
这些不是“性能开关”，而是把锁控制权从引擎层部分交还给应用，减少不可控等待。
-
SELECT ... FOR UPDATE NOWAIT：避免事务卡在锁等待上，应用可立即重试或降级 -
SELECT ... FOR UPDATE SKIP LOCKED：常用于任务队列消费，跳过已被其他事务锁定的行，无需改业务逻辑就能实现无锁并发取任务 - 死锁检测默认开启
innodb_deadlock_detect=ON，后台线程持续维护等待图，P99 锁等待延迟下降超 60%——但代价是 CPU 使用率 +3%～5% - 若确认业务绝无死锁可能（如所有 UPDATE 都严格按主键顺序执行），可关掉检测：
SET GLOBAL innodb_deadlock_detect=OFF，再配合innodb_lock_wait_timeout = 10做兜底
升级后最容易被忽略的兼容性断点
锁行为变“稳”了，但旧监控和业务逻辑可能直接失效。
-
SHOW ENGINE INNODB STATUS输出格式变更：LOCK WAIT 区块已结构化，字段如WAITING TRANSACTION、HOLDING LOCK替代了旧文本解析方式，硬编码正则会失败 -
performance_schema.data_locks成为唯一可靠来源，必须打开performance_schema并查该表才能看清实际锁住哪些记录 - DDL 操作获取
MDL_EXCLUSIVE更严格，FLUSH TABLES WITH READ LOCK在 8.0 下直接报错，备份脚本需重写 - 临时表
CREATE TEMPORARY TABLE也参与 MDL 管理，高频创建/删除场景要调大metadata_locks_cache_size
真正决定多核能不能跑满的，从来不是参数设了多少，而是你的核心 SQL 在 performance_schema.data_locks 里锁住了什么、锁了多久、有没有集中在同一 page 或 hash bucket 上——先看这个，再调参。
