Seconds_Behind_Master 在并行复制下是「假指标」：你们线上怎么合成一个能区分「真追不上」和「瞬时抖动」的从库真实延迟指标，作为故障切换判据？

背景

3 年运维，负责一套 MySQL 8.0.36 订单库（主 16C64G + 2 台从，binlog=row，已开 LOGICAL_CLOCK 并行复制 worker=8，GTID 全开）。最近在给故障切换（MHA 自托管脚本）写「该不该切」的判定逻辑，卡在一个很具体的问题上：用哪个指标判定「从库真的追不上了」，而不是「从库此刻恰好有个大事务在重放」。

现象（线上实测的三次反例）

1. 并行复制下 Seconds_Behind_Master 会「锯齿」：worker 并发重放时该值不单调，同一个 binlog 位置重放 3 秒，指标在 0.3s ↔ 1.8s 之间跳。用它做「连续 3 次 > 5s 就切」的判定，压测里连续误报 2 次。
2. GTID 距离换算的坑：我试过用 gtid_executed 差值估算落后事务数（主 exec 12,431,208 条 / 从 12,431,196 条 = 落后 12 条），但事务数 ≠ 时间：这 12 条里如果有一条 200 万行 UPDATE，落后时间是分钟级；如果都是点更新，落后时间是毫秒级。纯 GTID 差值给了个「假安心」。
3. Seconds_Behind_Master 断连时返回 NULL：网络抖断 20 秒，监控直接收不到值，切主脚本里 if lag > 5 在 NULL 上是 False——断连场景反而不触发切换，这正好是最该切的场景。

已尝试的排查与结果

• 读站内文章：《主从延迟 4.7 秒导致"写后即读"读串》(id=119) 讲了并行复制的三个瓶颈，但侧重「怎么把延迟降下来」，没讲「延迟指标本身怎么读」；《写主库读从库却读到旧数据》(id=436) 讲了半同步兜底，也没覆盖指标合成；《批量回刷千万行 UPDATE：闭环限速》(id=1897) 直接把 Seconds_Behind_Source 当反馈信号用，但那是批跑限速场景（容忍误报），切主场景不容忍。
• 自己写了个合成指标 v1：lag_time = 主库该 gtid 的 binlog 写入时间戳 − 从库重放完成时间，问题是主库 binlog 里没有逐事务时间戳（只有 binlog 文件级时间），退化成了「文件时间差」，精度不够。
• 试了 performance_schema 的 replication_applier_status_by_worker 拿每个 worker 的 LAST_APPLIED 时间戳做 max，方向对，但没想清楚怎么和「主库产生速率」配合成速率模型。

期望得到的答案形态（越具体越好）

1. 你们线上判定「从库真延迟」的指标合成公式：用了哪几个源（GTID 差值 / worker 时间戳 / relay log 积压字节数 / 主库写入速率），怎么加权或取 max？
2. 怎么区分「瞬时重放大事务」和「持续追不上」：时间窗口怎么取？判据是「速率对比」（主库 produce rate > 从库 apply rate 持续 N 秒）还是「绝对值 + 趋势」？
3. 断连 / NULL 场景的兜底判据是什么（心跳表？主库写入时间戳 vs 从库最后 apply 时间戳的时间差？）
4. 有没有踩过「指标说正常、实际数据不一致」的坑——比如 GTID 已执行但从库崩溃恢复后数据回滚的场景。

开放问题：如果从库延迟指标本身都不可信，那「延迟 > X 秒触发切主」这个业界惯例到底建立在什么假设上？想听听不同规模（单从 / 多从 / 异地多活）下的真实做法。