Seconds_Behind_Master不准，因其仅反映SQL线程最后回放事件的时间戳与从库当前时间的差值，不体现IO线程滞后、relay log堆积、大事务执行中last_master_timestamp停滞、主从时钟不同步（clock_diff_with_master单次快照失准）、并行复制下worker实际进度等关键延迟因素。

Seconds_Behind_Master 不准，是因为它根本不是“真实延迟”的测量值，而是一个受多个脆弱假设支撑的近似值——只要其中任一环节失准，结果就完全不可信。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

Seconds_Behind_Master 为什么总显示 0 却明显不同步

• 它只反映 SQL 线程刚回放完的那条 event 的时间戳和当前系统时间的差，不感知：
  • IO 线程是否已拉到最新 binlog（Read_Master_Log_Pos 远落后于主库 File/Position）
  • relay log 是否堆积（Relay_Log_Space 持续上涨但值卡死不动）
  • 大事务正在执行中，last_master_timestamp 根本没更新，但 time(0) 一直走 → 差值虚高，事务一提交就归零
• 常见假象：值为 0，但 Exec_Master_Log_Pos 长期不增长，Slave_SQL_Running_State 是 Waiting for commit lock 或 Updating + 一条慢 SQL

主从系统时间不同步会直接污染计算结果

• clock_diff_with_master 只在 IO 线程启动时查一次 SELECT UNIX_TIMESTAMP()，之后永不更新
• 若从库时间比主库快 2 秒，Seconds_Behind_Master 可能恒为 -2（显示为 0）；若慢 37 秒，可能长期卡在 37
• date +%s 对比不可靠：它只显示当前时间，不反映 NTP 实际校准偏移
  ✅ 正确检查方式：chronyc tracking（chronyd）或 ntpq -p（ntpd），盯 Offset 字段，超过 ±100ms 就该干预
• 禁用 systemd-timesyncd：它默认秒级精度，无法满足 MySQL 复制对毫秒级一致性要求

并行复制下 Seconds_Behind_Master 更不可信

• 开启 slave_parallel_workers > 0 后，该值只由 coordinator 线程计算，不体现 worker 实际执行进度
• 可能出现：SQL 线程状态是 Waiting for dependent transaction to commit，但值仍为 0
• slave_parallel_type = DATABASE 在单库多表场景基本无效，必须切到 LOGICAL_CLOCK 才能真正并行
• 真实延迟要看 SELECT GTID_SUBTRACT(@@global.gtid_executed, Retrieved_Gtid_Set) —— 结果非空，说明事务根本没传过来

别依赖单次 SHOW SLAVE STATUS，要盯组合指标和线程状态

• 关键三元组必须一起看：
  • Slave_IO_Running = Yes（IO 是否活着）
  • Slave_SQL_Running = Yes（SQL 是否活着）
  • Read_Master_Log_Pos == Exec_Master_Log_Pos（是否真正追平）
• Relay_Log_Space 涨但 Seconds_Behind_Master 不变 → SQL 线程被锁死，不是慢，是停了
• SHOW PROCESSLIST 中找 User: system user、Command: Connect 那行，看 State 和 Info，才是阻塞根源

真实延迟从来不在那个数字里，而在 Exec_Master_Log_Pos 是否移动、Slave_SQL_Running_State 是否卡住、以及主从时钟是否真正对齐。