MySQL 8.0 热点行更新性能提升源于高并发下锁争用减少和事务稳定性增强，关键依赖正确配置：调大 innodb_sync_array_size、关闭 innodb_deadlock_detect（若无死锁风险）、清理 FLUSH TABLES WITH READ LOCK 脚本。
MySQL 8.0 对热点行更新性能更好，不是因为单次 UPDATE 更快，而是高并发下锁等待更少、事务提交更稳——前提是必须用对配置，否则可能比 5.7 还慢。
锁管理器拆分后争用降低，但需配合 innodb_sync_array_size 调整
5.7 的 lock_sys->mutex 是全局一把锁，1000 QPS 更新同一行时，大量线程卡在锁获取上；8.0 把锁系统拆成多个细粒度 mutex 和 wait_mutex，并用哈希表分片（rec_hash、prdt_hash）分散压力。
- 默认分片数由
innodb_sync_array_size控制（8.0 默认 16），若观察到performance_schema.data_locks中行锁集中在少数 hash bucket，说明分片不均，应调大该值 - 旧监控脚本依赖
SHOW ENGINE INNODB STATUS解析 LOCK WAIT 输出，8.0 格式已变，会解析失败 - 实测中相同热点更新压测，8.0 的
innodb_row_lock_waits增长速率下降约 35%，但仅在锁竞争密集场景（如秒杀扣库存）才明显
间隙锁判断更精准，减少误锁但加锁路径变长
8.0 在二级索引上做 Gap Lock 判断时，会精确检查索引项之间的“空隙”是否真被其他事务覆盖；5.7 则倾向于保守加锁，容易把无关事务也拦住。
- 好处：热点商品详情页的
SELECT ... FOR UPDATE不再轻易锁住相邻无关记录，提升并发度 - 代价：单线程低并发（1–8 线程）下，加锁路径变长，反而略慢于 5.7
- 若业务以低并发点查为主，升级后没感知提升属正常现象，不必强行调优
MDL 锁升级更早、更确定，避免“DDL 卡死所有 DML”
8.0 的元数据锁（MDL）语义强化：DDL 操作前必须获取 MDL_EXCLUSIVE，且不允许被低优先级 DML 插队。这不是性能优化，而是行为收敛。
- 你不再会遇到 5.7 那种 “ALTER TABLE 卡住 30 秒后突然抢到锁，瞬间阻塞全部查询” 的抖动
- 代价是
lock_wait_timeout默认值（31536000 秒）更容易触发超时，生产环境建议显式设为60或120 -
FLUSH TABLES WITH READ LOCK在 8.0 下会被 MDL 拒绝，备份脚本里还留着这句会直接失败
死锁检测从“按需扫描”变为“持续追踪”，CPU 换响应确定性
5.7 死锁检测是被动的：只有事务等锁超时才启动一次全图遍历；8.0 默认开启 innodb_deadlock_detect=ON，后台线程持续维护等待图（wait-for graph），环一形成立刻回滚。
- 好处：热点行更新冲突时，回滚更及时，不会让一个事务卡住整个 worker 线程池
- 代价：持续维护图结构带来额外 CPU 开销，在极高并发（>512 线程）下可能成为瓶颈
- 若确认业务几乎无死锁（如纯单行主键更新），可关掉：
SET GLOBAL innodb_deadlock_detect=OFF
真正影响热点更新性能的，往往不是版本号本身，而是你有没有关掉 innodb_deadlock_detect、有没有调大 innodb_sync_array_size、有没有清理掉脚本里残留的 FLUSH TABLES WITH READ LOCK ——这些细节比“升级到 8.0”本身更关键。
