MySQL 8.0 并行复制利用率需从Coordinator分发与Worker负载交叉验证：Replica_worker_threads值长期≤2表明事务串行化，6–12波动才有效；持续满值需查replica_pending_jobs_size_max；SHOW PROCESSLIST看worker状态；performance_schema.replication_applier_status_by_coordinator分析分发均衡性；InnoDB history list>5000或purge线程不足会拖慢回放；主库无主键/依赖设置不当才是根本瓶颈。
MySQL 8.0 的并行复制线程利用率不能只看 CPU 使用率 或 Seconds_Behind_Master，必须从 Coordinator 分发行为和 Worker 实际负载两个层面交叉验证。
查 Replica_worker_threads 状态变量是否真实活跃
这个变量显示当前正在执行事务的 SQL worker 数量，是判断并行是否“跑起来”的第一指标。它和 slave_parallel_workers 设置值无关，只反映实时负载。
-
SHOW STATUS LIKE 'Replica_worker_threads';值长期 ≤ 2，说明大部分事务被强制串行化——大概率是主库binlog_transaction_dependency_tracking没设成WRITESET，或表缺失主键/唯一键 - 值在 6–12 之间波动且随写入压力上升，才算有效利用；若一直卡在最大值（比如设了 16 却始终是 16），要检查
replica_pending_jobs_size_max是否过小导致队列阻塞 - 该值为 0 表示 Coordinator 暂无事务可分发（空闲），不是故障；但若持续 > 0 且
Seconds_Behind_Master却飙升，说明 worker 处理不过来，可能遇到锁冲突或大事务
用 SHOW PROCESSLIST 看 worker 真实状态
仅靠状态变量不够，得进线程现场看它们到底在等什么。
- 执行
SHOW PROCESSLIST;，过滤出State含Slave_worker的行 - 如果多数处于
Waiting for an event from Coordinator：正常，说明 Coordinator 有活干、worker 在等任务 - 如果大量是
Waiting for preceding transaction to commit：事务间依赖太重，WRITESET没生效或存在跨表更新同一行的情况 - 出现
Updating或Query end但长时间不退出：可能遭遇唯一键冲突、DDL 锁表，或事务本身过大（>100 行）卡在一个 worker 里
盯紧 performance_schema.replication_applier_status_by_coordinator
这是 MySQL 8.0 提供的最细粒度的并行调度视图，能暴露 Coordinator 分发是否均衡。
- 查
WORKERS_PROCESSED和WORKERS_WAITING比例：若前者远小于后者（比如 1:5），说明事务分发策略有问题，大量事务堆积在 Coordinator 队列里没下发 - 关注
LAST_SEEN_TRANSACTION对应的 GTID，结合主库SHOW MASTER STATUS判断是否某类事务（如含特定表的 DML）被集中压到单个 bucket - 该表每秒刷新，建议用脚本每 5 秒采样一次，画趋势图——突然的
WORKERS_WAITING暴涨往往对应主库某批批量更新
别漏掉 InnoDB 层的隐性瓶颈
Worker 线程跑不满，有时根本不是复制层的问题，而是 InnoDB 回滚段或 purge 跟不上。
- 执行
SHOW ENGINE INNODB STATUS\G，在TRANSACTIONS部分看history list length：持续 > 5000 就危险，说明未清理的 undo 太多，worker 回放被 purge 线程拖住 - 检查
innodb_purge_threads是否 ≥ 4（默认是 4），低于此值在高更新场景下 purge 易成瓶颈 -
innodb_buffer_pool_size过小会导致 worker 频繁读盘，表现为 CPU 利用率低但iowait高——此时加 worker 反而加剧 IO 争抢
真正难调的点在于：并行利用率低，90% 情况下不是参数没设对，而是主库写法和表结构把并行能力锁死了。比如一个日志表没主键、所有 insert 都走 COMMIT_ORDER，再怎么调 slave_parallel_workers 也没用。
