mysql 8.0+中可通过performance_schema.replication_connection_status、replication_applier_status_by_coordinator和replication_applier_status_by_worker三张表分别监控io接收、协调器分发、工作线程回放环节的延迟，精准定位卡点。
Performance Schema里哪些表能看复制延迟
MySQL 8.0+ 的 performance_schema 提供了比 SHOW REPLICA STATUS 更细粒度的复制状态观测能力，核心是三张表：replication_connection_status、replication_applier_status_by_coordinator、replication_applier_status_by_worker。它们分别对应 IO 线程接收、协调器分发、工作线程回放三个阶段，能准确定位卡点在哪个环节。
注意：这些表默认启用，但需确保 performance_schema 开启（SELECT @@performance_schema 返回 1），且复制线程处于运行中（Replica_IO_Running = Yes、Replica_SQL_Running = Yes）。
怎么看IO线程是否卡在接收环节
查 replication_connection_status 表，重点关注 LAST_HEARTBEAT_TIMESTAMP 和 CONNECTED 字段：
-
CONNECTED = NO：IO 线程断连，不是延迟而是中断，优先排查网络或主库 dump thread 是否存活 -
LAST_HEARTBEAT_TIMESTAMP明显滞后于当前时间（比如差 5 秒以上）：说明主库 binlog 推送慢或从库 IO 线程写 relay log 受阻（常见于sync_relay_log = 1+ 高频小事务） -
LAST_ERROR_NUMBER非 0：IO 线程报错，如2013（连接丢失）、1236（binlog position 不匹配）
示例查询：
SELECT CHANNEL_NAME, CONNECTED, LAST_HEARTBEAT_TIMESTAMP, LAST_ERROR_NUMBER, LAST_ERROR_MESSAGE FROM performance_schema.replication_connection_status;
怎么判断是SQL线程回放慢还是分发慢
先看协调器状态：replication_applier_status_by_coordinator 中 THREAD_ID 为空表示未启用并行复制；若非空，检查 WORKERS_PROCESSED 和 WORKERS_IDLE 比值 —— 如果大量 worker 处于 idle，但 APPLYING_TRANSACTION 卡住，说明协调器没及时分发任务，可能因事务依赖检测开销大（如 GTID mode + 复杂事务图）。
再看工作线程：replication_applier_status_by_worker 中每行代表一个 worker，关键字段：
-
LAST_APPLIED_TRANSACTION：该 worker 最后执行的事务 ID -
LAST_APPLIED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP：该事务在主库的实际提交时间（微秒级） -
LAST_APPLIED_TRANSACTION_START_QUEUE_TIMESTAMP：该事务进入 relay log 队列的时间
用这两个时间戳相减，就能算出「排队时长」；再和 NOW(6) 相减，得出「已落后多少秒」——这比 Seconds_Behind_Master 更真实，尤其对大事务中间状态有效。
容易被忽略的坑：timestamp精度与GTID模式依赖
ORIGINAL_COMMIT_TIMESTAMP 是 MySQL 8.0 引入的 WL#7319 特性，它只在 binlog event 中存在，且依赖主库开启 binlog_transaction_compression = OFF（压缩会丢时间戳）。如果主库用了压缩或版本低于 8.0，这张表里的 timestamp 全为 0，所有延迟计算失效。
另外，replication_applier_status_by_worker 的事务 ID 格式取决于是否启用 GTID：
– GTID 模式下是 UUID:NUMBER，可跨实例比对
– 非 GTID 模式下是 file_name:position，仅限本实例内有效，无法关联到主库 binlog 位置
所以真要靠 Performance Schema 做精准延迟归因，必须确认：主从都为 MySQL 8.0+、GTID 开启、binlog 压缩关闭、且 performance_schema 全量采集项未被裁剪（setup_consumers 中相关 consumer 启用）。
