replica_worker_threads是判断并行复制是否真正运行的核心指标：值长期≤2表明事务被强制串行化，6–12波动说明有效利用，持续满值需查队列阻塞或回放瓶颈，为0表示coordinator空闲。
Replica_worker_threads状态变量怎么看
Replica_worker_threads 是判断并行复制是否真正跑起来的最直接指标，它反映的是当前正在执行事务的 SQL worker 数量，不是配置值，也不是 CPU 使用率。这个值必须实时观察，不能只看一次。
- 值长期 ≤ 2：大概率事务被强制串行化，不是线程没开，而是主库没产生可并行的事务组——检查主库
binlog_transaction_dependency_tracking是否为WRITESET、表是否有主键/唯一键 - 值在 6–12 之间随写入压力波动：说明分发和回放基本健康，worker 在有效轮转
- 值持续卡在最大值（比如设了 16 就一直是 16）：可能
replica_pending_jobs_size_max过小导致队列阻塞，或 worker 处理不过来（锁冲突、大事务、purge 滞后） - 值为 0：Coordinator 当前无事务可分发，属于空闲态，不是异常
SHOW PROCESSLIST里Worker到底在等什么
仅靠状态变量不够，得进现场看线程真实行为。执行 SHOW PROCESSLIST;，过滤出 State 含 Slave_worker 的行（MySQL 8.0.26+ 实际显示为 Replica_worker，但旧监控脚本可能仍匹配 Slave_worker）。
- 多数是
Waiting for an event from Coordinator：正常，说明 Coordinator 有活干，worker 在排队领任务 - 大量是
Waiting for preceding transaction to commit：事务依赖过重，WRITESET没生效，或存在跨表更新同一行、session 内连续操作等场景 - 卡在
Updating或Query end超过 30 秒：大概率遇到唯一键冲突、DDL 锁表，或单事务修改行数超 100 行，被钉在一个 worker 里
performance_schema.replication_applier_status_by_coordinator怎么用
这是 MySQL 8.0 提供的最细粒度调度视图，能暴露 Coordinator 分发是否失衡。重点看 WORKERS_PROCESSED 和 WORKERS_WAITING 两列。
- 若
WORKERS_PROCESSED远小于WORKERS_WAITING（如 1:5），说明事务堆积在 Coordinator 队列里没下发，不是 worker 不够，而是分发策略或依赖判断出了问题 - 结合
LAST_SEEN_TRANSACTION的 GTID，去主库查对应事务内容，确认是否某类操作（如批量更新某张无主键表）集中压到一个 bucket - 该视图每行代表一个 replication channel，多通道部署时需逐个检查
为什么Seconds_Behind_Master不准
Seconds_Behind_Master（8.0.26+ 显示为 Seconds_Behind_Source）是估算值，受主库 clock skew、网络抖动、事务大小影响极大，不能用来判断 worker 利用率。
- 延迟为 0 但
Replica_worker_threads长期 ≤ 2：说明复制没瓶颈，但并行根本没启用 - 延迟飙升但
Replica_worker_threads始终满值：说明 worker 回放慢，要查InnoDB history list length是否 > 5000（purge 拖累）、是否有长事务阻塞回滚段 - 真正瓶颈往往不在 SQL 线程本身，而在 InnoDB 层：比如
innodb_thread_concurrency设太低、buffer pool 争用、或主库 binlog 写放大严重
容易被忽略的一点：即使所有参数都配对了，只要主库有一张表缺失主键或唯一键，WRITESET 就会自动 fallback 到 COMMIT_ORDER，整个复制链路退化为逻辑串行——这种问题不会报错，但 worker 利用率永远上不去。
