mysql 8.0通过writeset并行复制、锁分配器重构、mdl语义收敛和死锁检测机制升级，显著提升高并发下的稳定性与可控性，但需严格匹配配置并调整运维习惯。
WRITESET 并行复制让 SQL 线程不卡死
MySQL 8.0 在高并发写入下更稳定，核心不是“整体更快”，而是从库 SQL 线程回放不再动不动卡在 Waiting for an event from Coordinator。5.7 的 LOGICAL_CLOCK 并行依赖主库“凑组”——只有同一刷盘批次的事务才共享 last_committed，否则一律串行；而 8.0 的 WRITESET 直接看行级变更是否重叠，哪怕两个事务相隔几分钟、改的是不同表，只要 write_set 无交集（比如 {hash(orders:1001)} 和 {hash(products:99)}），就能并行回放。
常见错误现象：
- 定时任务每秒单条
UPDATE，5.7 中last_committed几乎总是递增，SQL 线程彻底退化为单线程 - 低峰期或单线程写入应用，5.7 长期卡在
Slave_SQL_Running_State的等待状态 - 两个事务明明改不同行，只因没进同一组，就被强制串行
配置 WRITESET 必须同时满足三项，缺一不可：
- 主库设
binlog_transaction_dependency_tracking = WRITESET - 主库保持
transaction_write_set_extraction = XXHASH64（默认值，别乱改） - 从库设
slave_parallel_type = LOGICAL_CLOCK（注意：不是WRITESET！WRITESET是 dependency tracking 模式，不是 parallel_type）
锁分配器重构缓解高并发争用
8.0 彻底重写了 lock_sys 结构，把 5.7 中那个全局一把大锁（lock_sys->mutex）拆成多个细粒度锁（mutex、wait_mutex），并引入哈希表分片（rec_hash、prdt_hash）。这直接降低了锁管理器自身成为瓶颈的概率。
实操中你能感知到的是：
- 同样 1000 QPS 的热点行更新压测下，
innodb_row_lock_waits增长更平缓，innodb_row_lock_time_avg下降约 35% - 旧版监控脚本若硬解析
SHOW ENGINE INNODB STATUS中的LOCK WAIT输出，大概率失败——8.0 输出格式已变 - 若观察到
rec_hash负载不均（可通过performance_schema.data_locks行号分布粗略判断），可调大innodb_sync_array_size
MDL 锁语义更严格，阻塞更早但更可控
8.0 对元数据锁（MDL）做了行为收敛：DDL 操作前必须获取 MDL_EXCLUSIVE，且不允许被低优先级 DML “插队”。这不是性能提升，而是把原来 5.7 中那种“ALTER TABLE 卡住几十秒后突然抢到锁，接着瞬间阻塞所有查询”的不可控状态，变成明确、可预期的等待。
代价是更容易触发 lock_wait_timeout 超时（默认 31536000 秒），尤其当存在长事务未提交时。生产环境建议显式设为 60 或 120，并配合应用层重试逻辑。
需特别注意：
-
FLUSH TABLES WITH READ LOCK在 8.0 下会被 MDL 机制拒绝执行，备份脚本里还留着这句会直接失败 - 临时表（
CREATE TEMPORARY TABLE）现在也参与 MDL 管理，高频创建/删除临时表的应用要关注metadata_locks_cache_size - 检查当前 MDL 等待，应查
performance_schema.metadata_locks表，重点关注LOCK_STATUS = 'PENDING'的记录
死锁检测从“按需扫描”变为“持续追踪”
5.7 的死锁检测是被动的：只有事务在 innodb_lock_wait_timeout 内拿不到锁，才会启动一次全图遍历；8.0 默认开启 innodb_deadlock_detect = ON，后台线程持续维护等待图（wait-for graph），一旦成环立即回滚。
好处是死锁响应时间从秒级降到毫秒级；坏处是高并发短事务场景下 CPU 使用率可能上升——这是用 CPU 开销换来的确定性。
如果你发现 CPU 虚高且集中在内核态（%sys 时间比 5.7 高出 15–20%），别急着关 innodb_deadlock_detect，先确认是不是 performance_schema 全量开启导致的 cache thrashing（尤其是 events_statements_current 和 events_waits_current）。
真正容易被忽略的点是：WRITESET 和 MDL 的稳定性收益，都建立在配置匹配和行为收敛的基础上。你不能只升级版本就指望自动变稳——主从参数漏配一项，或者备份脚本里还留着 FLUSH TABLES WITH READ LOCK，照样崩得干脆利落。
