直接查replica_worker_threads状态变量，它反映此刻正在执行事务的sql worker数量；值长期≤2说明串行化，6–12波动才健康，持续满值需查replica_pending_jobs_size_max或锁等待。
怎么看当前有几个Worker线程在干活
直接查 Replica_worker_threads 状态变量，它反映的是**此刻正在执行事务的 SQL worker 数量**，不是你设的 slave_parallel_workers 值。这个数字才是并行是否真正跑起来的第一证据。
- 值长期 ≤ 2：大概率被强制串行化了，重点检查主库是否开了
binlog_transaction_dependency_tracking=WRITESET，或从库表缺主键/唯一键 - 值在 6–12 之间随写入压力波动：说明并行调度基本健康
- 值一直卡在最大值（比如设了 16 就一直是 16）：可能是
replica_pending_jobs_size_max太小导致队列堵住，或者 worker 全卡在等锁、等提交 - 值为 0：Coordinator 暂无事务可分发，不一定是故障，但若持续为 0 且
Seconds_Behind_Master却飙升，就要查 IO 线程是否真的在收日志
怎么用 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卡住超过 10 秒：大概率是大事务（>100 行）、唯一键冲突、DDL 锁表，或遇到 InnoDB 行锁争用 - 如果多数 worker 都卡在
Locked或update状态，要立刻查information_schema.INNODB_TRX和INNODB_LOCK_WAITS
怎么查 Coordinator 分发是否均衡
关键视图是 performance_schema.replication_applier_status_by_coordinator，它暴露了事务分发层的细节：
- 看
WORKERS_PROCESSED和WORKERS_WAITING比例：若前者远小于后者（比如 1:5），说明事务堆积在 Coordinator 队列里没下发，不是 worker 不够，而是分发策略或依赖判断出了问题 - 结合
LAST_SEEN_TRANSACTION的 GTID，去主库查对应事务内容——如果连续多个都是大事务或含CREATE TABLE AS SELECT，那这些事务天然不可并行，worker 再多也白搭 - 该视图只在 MySQL 8.0+ 可用；如果查不到，确认
performance_schema已启用且复制已启动
为什么 performance_schema.replication_applier_status_by_worker 显示的线程数对不上
这个视图里的记录数 = 当前配置的 slave_parallel_workers 值，但每条记录的 APPLIER_STATE 字段才决定它是否真在干活：
-
APPLIER_STATE = 'ACTIVE'：正在执行事务 -
APPLIER_STATE = 'IDLE'：空闲，但线程存在 -
APPLIER_STATE = 'ERROR'：该 worker 出错了，得结合LAST_ERROR_MESSAGE看具体原因（比如某张表结构不一致） - 注意：即使
APPLIER_STATE = 'IDLE'，只要Replica_worker_threads> 0，就说明有 worker 在处理事务——别只盯着这个视图数线程个数
last_committed 和 sequence_number 是否允许错开。这些元数据一旦生成就无法更改，所以调优必须从主库配置和业务写法入手，而不是光在从库加线程。
