mysql 8.0中，performance_schema.replication_applier_status表的remaining_delay字段是唯一反映真实延迟等待时间的指标，仅在启用source_delay且从库正等待延迟过期时非null；seconds_behind_source不在performance schema中，需通过show replica status或information_schema.replica_hosts获取；replication_applier_status_by_worker用于诊断并行回放瓶颈；replication_connection_configuration中的source_delay仅为静态配置值，非实时延迟。
直接看 replication_applier_status 表的 REMAINING_DELAY
MySQL 8.0 中，performance_schema.replication_applier_status 是唯一能反映「真实延迟等待时间」的 Performance Schema 表。它不依赖 SQL 线程是否空闲，只在从库明确处于「等待 DESIRED_DELAY 过期」状态时才非 NULL。也就是说：REMAINING_DELAY 有值，就代表当前正卡在人为设置的延迟复制上；为 NULL，说明没在等延迟（哪怕 Seconds_Behind_Source 是 120，它也可能是 0 或 NULL）。这个字段和 CHANGE REPLICATION SOURCE TO SOURCE_DELAY = N 配套使用，仅对启用了延迟复制的从库有效。
Seconds_Behind_Source 在 Performance Schema 里查不到
别白费劲去 performance_schema 里翻表找 Seconds_Behind_Source——它压根不在那里。这个值只存在于 SHOW REPLICA STATUS 的输出中，底层由复制线程状态实时计算，Performance Schema 并未将其导出为列。很多监控脚本误以为 replication_connection_status 或 replication_applier_status_by_coordinator 里有对应字段，结果查出来全是 NULL。真要采集它，只能解析 SHOW REPLICA STATUS 输出，或用 information_schema.REPLICA_HOSTS（MySQL 8.0.33+）配合外部工具轮询。
用 replication_applier_status_by_worker 判断并行回放瓶颈
当启用 slave_parallel_type = LOGICAL_CLOCK 或 WRITESET 后，真正干活的是多个 worker 线程。此时 performance_schema.replication_applier_status_by_worker 比 Seconds_Behind_Source 更有诊断价值：
-
WORKER_ID显示哪个 worker 卡住了（比如 ID=3 长期LAST_APPLIED_TRANSACTION不变） -
LAST_APPLIED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP和LAST_APPLIED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP差值大，说明事务在 relay log 里积压久，IO 线程或网络可能拖后腿 -
APPLYING_TRANSACTION为 YES 但LAST_APPLIED_TRANSACTION_START_APPLY_TIMESTAMP老不更新，大概率是单个大事务阻塞了整个 worker 队列
注意：该表只在 slave_parallel_workers > 0 且 SQL 线程已启动时才有数据，刚执行 START REPLICA 后可能需等几秒才填充。
别把 replication_connection_configuration 当延迟指标
performance_schema.replication_connection_configuration 只存连接参数（如 HOST、PORT、SOURCE_DELAY），其中 SOURCE_DELAY 是你设的「目标延迟值」，不是当前延迟。它不会随实际同步进度变化。常见错误是监控脚本把它当实时延迟读取，结果告警永远触发不了——因为 SOURCE_DELAY = 300 是静态配置，哪怕从库已经追平，这值还是 300。
真正容易被忽略的是：Performance Schema 监控主从延迟，本质只解决「人为延迟」和「并行回放卡点」两类问题；对于普通异步复制下的真实 lag（比如主库狂写、从库 IO 压力大），仍得靠 SHOW REPLICA STATUS + 位点比对 + GTID_SUBTRACT 手段交叉验证。指望一张表包打天下，迟早掉坑里。
