判断 MySQL 主从延迟需综合多种方法：优先看 Seconds_Behind_Master，但需注意其局限性；其次比对 Master_Log_File/Read_Master_Log_Pos 与 Relay_Master_Log_File/Exec_Master_Log_Pos 位点；GTID 模式下可用 GTID_SUBTRACT 对比缺失事务；业务层通过心跳表计算端到端延迟最真实。
判断 MySQL 主从延迟，核心是对比主库写入时间与从库执行完成时间的差值。最直接有效的方式是通过 Seconds_Behind_Master 值，但该值有局限性，需结合其他指标交叉验证。
看 Seconds_Behind_Master（最常用但需谨慎）
在从库执行 SHOW SLAVE STATUSG，关注 Seconds_Behind_Master 字段：
- 值为 0：通常表示无延迟（前提是 IO 线程和 SQL 线程都为 Yes）
- 值为 NULL：说明 SQL 线程未运行（可能出错、被暂停或 relay log 读取异常）
- 值为正数：表示从库 SQL 线程落后主库多少秒（基于主库 binlog 事件的时间戳计算）
⚠️ 注意：该值在以下情况会失真：
- 主库时钟不准确（如 NTP 未同步），导致时间戳偏差
- 主库长时间空闲，binlog 时间戳陈旧，而从库实际已追平
- 从库启用了多线程复制（MTS），且使用 LOGICAL_CLOCK 算法时，该值仅反映最慢 worker 的延迟，不能代表整体进度
比对位点（更可靠：Master_Log_File + Read_Master_Log_Pos vs Relay_Master_Log_File + Exec_Master_Log_Pos）
仍用 SHOW SLAVE STATUSG，提取四组关键位点：
- Master_Log_File / Read_Master_Log_Pos：IO 线程已从主库拉取到的最新 binlog 文件和位置
- Relay_Master_Log_File / Exec_Master_Log_Pos：SQL 线程已执行完的主库 binlog 文件和位置
若前两者与后两者完全一致（文件名相同、位置相同），说明从库已实时追上；若有差异，差值即为未执行的 binlog 字节 数，可粗略估算延迟量。配合 mysqlbinlog 查看对应位置的 event 时间戳，能算出真实延迟秒数。
用 GTID 对比（适用于开启 GTID 的环境）
执行 SELECT @@global.gtid_executed; 分别在主库和从库运行：
- 从库的 gtid_executed 应该是主库的子集
- 用
SELECT GTID_SUBTRACT(@@global.gtid_executed_on_master, @@global.gtid_executed_on_slave);可查出从库缺失的事务集合 - 缺失的 GTID 数量越多、越新，延迟越严重
GTID 方式不受文件名 / 位置变更影响，逻辑清晰，适合自动化监控脚本使用。
业务层打点验证（最真实：端到端延迟）
在主库插入一条带当前时间戳的记录（例如：INSERT INTO heartbeat(ts) VALUES(NOW());），然后在从库持续查询该记录的 ts 值，计算当前时间与该值的差值：
- 这个差值反映的是 应用可见的延迟，包含网络、复制、SQL 执行、锁等待等全链路耗时
- 建议每秒写一次心跳，并保留最近 10 条，避免单次抖动误判
- 比数据库内部指标更能体现真实业务影响
不复杂但容易忽略。
