MySQL 5.7中如何监控并行复制的每个Worker状态_查询replication_applier_status_by

replication_applier_status_by_worker是mysql 5.7并行复制的核心监控表，用于实时查看各worker线程的执行进度、延迟和错误；关键字段包括worker_id、service_state、last_seen_transaction、last_error_number、last_error_message和applying_transaction。

mysql 5.7中如何监控并行复制的每个worker状态_查询replication_applier_status_by_worker

直接查`replication_applier_status_by_worker`就能看到每个worker实时状态

MySQL 5.7开启并行复制后，replication_applier_status_by_worker是唯一能逐个观察每个worker线程执行进度、延迟和错误的系统表。它不是“可选监控项”，而是诊断并行是否真在跑、哪个worker卡住、有没有事务堆积的核心依据。

`replication_applier_status_by_worker`里哪些字段最关键

这张表在performance_schema库下，必须先USE performance_schema再查。重点关注以下字段：

WORKER_ID：worker编号，从1开始，对应你设的slave_parallel_workers值
THREAD_ID：该worker对应的内部线程ID，可用于进一步查threads表确认状态
SERVICE_STATE：取值ON或OFF，OFF说明该worker已退出（常见于报错后自动停）
LAST_SEEN_TRANSACTION：最近执行的事务GTID，对比主库SHOW MASTER STATUS可判断滞后多少
LAST_ERROR_NUMBER和LAST_ERROR_MESSAGE：有值就代表这个worker曾失败过，哪怕现在SERVICE_STATE=ON，也可能刚恢复
APPLYING_TRANSACTION：当前正在执行的事务GTID，为空说明空闲；非空但长时间不变，大概率卡住了

为什么`SELECT * FROM replication_applier_status_by_worker\G`常显示空结果

这不是数据丢了，而是你没启用performance_schema或相关instrument没开。必须确认以下三点：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

启动MySQL时加了--performance-schema=ON（5.7默认开，但某些精简包或Docker镜像会关）
运行SELECT VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'performance_schema'，返回ON
SELECT * FROM performance_schema.setup_instruments WHERE NAME = 'thread/sql/slave_worker'结果中ENABLED和Timed都为YES；若否，需UPDATE performance_schema.setup_instruments SET ENABLED='YES', TIMED='YES' WHERE NAME='thread/sql/slave_worker'

查到某个worker `SERVICE_STATE=OFF`但复制还在跑，怎么办

这说明coordinator线程把活分给了其他worker，当前worker因错误退出——但MySQL不会自动重启它，也不会报错到SHOW SLAVE STATUS的Seconds_Behind_Master里。此时必须人工干预：

先看LAST_ERROR_MESSAGE，90%是Deadlock found when trying to get lock或Cannot execute statement: binlog logging is disabled这类可重试错误
执行STOP SLAVE; START SLAVE;可强制重建所有worker（注意：会短暂中断复制）
如果错误反复出现，检查主库是否混用了STATEMENT格式binlog（slave_parallel_type=LOGICAL_CLOCK要求binlog_format=ROW）
别依赖Seconds_Behind_Master判断健康度——它只反映coordinator整体进度，worker级故障会被掩盖

真正容易被忽略的是：即使所有worker都显示ON，只要APPLYING_TRANSACTION长期不更新，或者多个worker的LAST_SEEN_TRANSACTION差距极大（比如一个在uuid:1000，另一个卡在uuid:500），说明事务分配不均或存在隐式锁等待，这时得结合SHOW PROCESSLIST看worker线程实际在做什么。