Seconds_Behind_Master不准，因其仅反映SQL线程执行延迟，不包含网络传输、主库写入时间戳漂移，且GTID模式下易失真；应结合GTID差集、时间戳对比等方法测真实延迟。
查 Seconds_Behind_Master 为什么不准
MySQL 官方的 Seconds_Behind_Master 看起来最直接，但它只反映 IO 线程拉取到 relay log 后、SQL 线程执行完的延迟，不包含网络传输时间、主库写入时间戳漂移、甚至可能为 NULL 或 0（比如 SQL 线程空闲但实际没追上）。尤其在 GTID 模式下，主从位点不严格对齐时，这个值容易失真。
实操建议：
- 先确认状态：
SHOW SLAVE STATUS\G，重点看Seconds_Behind_Master、Read_Master_Log_Pos和Exec_Master_Log_Pos是否在变化 - 如果值长期为
0但业务写入明显未同步，大概率是 SQL 线程卡住或复制过滤规则导致跳过事件 - GTID 模式下更应关注
Retrieved_Gtid_Set和Executed_Gtid_Set的差集，用SELECT GTID_SUBTRACT(...)查漏掉的事务
用时间戳字段 + 主从查询对比测真实延迟
这是最贴近业务感知的测法：在主库插入带当前时间的记录，立刻在从库查同一条记录的时间字段，差值就是端到端同步延迟。关键在于时间必须来自数据库服务端（不是应用层 now()），且主从服务器时钟需基本一致（误差建议
实操建议：
- 建测试表：
CREATE TABLE sync_test (id INT PRIMARY KEY, ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP); - 主库写入：
INSERT INTO sync_test (id) VALUES (1) ON DUPLICATE KEY UPDATE ts = CURRENT_TIMESTAMP;（避免重复失败） - 从库查：
SELECT UNIX_TIMESTAMP(ts) FROM sync_test WHERE id = 1;，与主库执行时刻（可用SELECT UNIX_TIMESTAMP(NOW());记录）做减法 - 注意：不能用
SLEEP(1)等待，必须立即查；多次执行取中位数，避开瞬时抖动
写脚本自动跑延迟检测要注意什么
自动化脚本核心是「写-查-算」闭环，但容易在连接、超时、并发和错误处理上翻车。常见现象是脚本跑着跑着就卡住，或者返回 0 延迟但实际不同步。
实操建议：
- 主从连接必须用独立账号，权限仅限
SELECT和INSERT，避免脚本误操作 - 每个操作加超时：
mysql --connect-timeout=3 --execution-timeout=5 -h master ... -e "INSERT ..." - 不要复用同一个连接查主从——主库连接不能查从库数据，否则会绕过复制链路
- 遇到
ERROR 1236 (HY000)或Slave_SQL_Running: No应立刻退出并报错，而不是继续测延迟
为什么 pt-heartbeat 是更稳的选择
Percona Toolkit 的 pt-heartbeat 不依赖时间戳字段或业务表结构，它用专用心跳表 + 时间戳列 + 每秒更新机制，通过计算从库读取该行的时间与写入时间之差得出延迟。它规避了时钟不同步、事务阻塞、主从时区差异等问题。
实操建议：
- 部署前确保主从都开启
binlog_format = ROW，否则语句级复制会导致从库更新时间不准确 - 心跳表必须建在主库，并由
pt-heartbeat在主库持续更新：pt-heartbeat --update -D test --table heartbeat --daemonize - 从库查延迟：
pt-heartbeat --check -D test --table heartbeat -h slave_host，输出即为秒级延迟 - 别忽略
--stop参数——脚本退出前要停掉守护进程，否则残留心跳会污染后续测试
真正难的不是写个脚本去比时间，而是让每次写入都可被精确追踪、每次查询都不受复制中断或锁影响。很多团队卡在“看起来同步了，但关键时刻丢数据”，问题往往出在没区分 Exec_Master_Log_Pos 和实际业务可见性之间那几百毫秒的黑盒里。
