mysql 8.0 并行复制未跑满cpu的主因是writeset依赖检测过于保守，同一行（即使不同列）修改即强制串行，导致高并发单表写入时并行度卡在2–4；需通过多表分散写、确保主键、调优参数及监控关键指标来释放真实并行能力。
为什么 MySQL 8.0 的并行复制没跑满 CPU？
MySQL 8.0 默认开启 binlog_transaction_dependency_tracking = WRITESET，但实际并行度常卡在 2–4 个线程，远低于物理核数。根本原因不是线程数设得少，而是事务间依赖检测太保守：只要两个事务修改同一行（哪怕不同列），就强制串行。压测时大量单表写入（如日志表 event_log）会高频触发这种假依赖。
实操建议：
- 先查真实并行度：
SHOW STATUS LIKE 'Replica_thread_count';和SHOW PROCESSLIST;看replica_sql_thread下活跃的worker数量 - 临时关闭依赖追踪验证效果：
SET GLOBAL binlog_transaction_dependency_tracking = 'COMMIT_ORDER';（仅测试用，主库 binlog 顺序语义会弱化） - 确认表有主键或唯一键——
WRITESET依赖检测必须依赖键值哈希，无主键的表自动退化为 COMMIT_ORDER
如何设计压测让并行复制“显形”？
用单线程客户端往多个独立业务表并发写入，才能逼出并行度。比如同时向 order_202401、order_202402、user_profile、payment_log 插入数据，每张表用不同主键段（如 order_id 范围隔离），避免跨表锁竞争和 writeset 冲突。
关键控制点：
- 禁用 autocommit，每个事务只写 1–3 行，模拟真实业务粒度；大事务（>100 行）会被整个塞进一个 worker
- 主库
innodb_flush_log_at_trx_commit = 2，避免日志刷盘成为瓶颈，让吞吐瓶颈真正落在复制层 - 从库
replica_parallel_workers = 16（建议设为 CPU 核数的 75%），但需同步调高replica_pending_jobs_size_max（默认 128MB），否则队列满后 worker 集体阻塞
性能对比实验必须监控的 3 个指标
别只看 Seconds_Behind_Master，它抖动大、延迟反馈滞后。真正反映并行效率的是：
-
Replica_worker_threads状态变量：持续高于 8 才算有效并行；如果长期 ≤ 2，说明 writeset 检测把大部分事务归到同一个 hash bucket - 从库
SHOW ENGINE INNODB STATUS中的TRANSACTIONS部分，观察history list length是否稳定——飙升说明回滚段堆积，worker 处理不过来 - 用
pt-heartbeat在主库每秒插入心跳，从库查heartbeat.ts延迟，比Seconds_Behind_Master更准，尤其对空闲期后的突发流量
WRITESET + GTID 下最容易被忽略的坑
开启 enforce_gtid_consistency = ON 后，某些隐式操作会破坏 writeset 计算。例如在存储过程中执行 CREATE TEMPORARY TABLE，MySQL 会为该 DDL 自动生成一个隐式事务，且不带 writeset hash，导致后续所有事务被阻塞等待这个“幽灵事务”提交。
排查方法：
- 从库错误日志搜
Waiting for preceding transaction to commit - 主库
mysqlbinlog --base64-output=DECODE-ROWS -v解析 binlog，检查事务末尾是否有孤立的GTID_LOG_EVENT无对应WRITESET字段 - 压测前先关掉所有含临时表/动态 SQL 的存储过程，或改用
COMMIT_ORDER模式绕过
并行复制的收益高度依赖业务写模式，不是调几个参数就能翻倍。最有效的优化往往发生在应用层：把单表高频小事务，拆成多表分散写入，并确保每张表都有明确主键。
