最可靠方法是执行 show slave status\g，关键看 relay_master_log_file 和 exec_master_log_pos 字段，二者共同标识从库已执行完主库的 binlog 文件名及偏移量。
怎么查从库当前同步到主库哪个 binlog 位置
直接看 SHOW SLAVE STATUS\G 最可靠。关键字段是 Relay_Master_Log_File 和 Exec_Master_Log_Pos，它们合起来就是“从库已执行完主库的哪个 binlog 文件、哪个偏移量”。别只盯着 Seconds_Behind_Master——它可能为 0 但实际卡在 IO 线程，也可能因为主库空闲而误报延迟。
常见错误现象：Seconds_Behind_Master 显示 NULL 或负数，通常意味着 SQL 线程没在运行（比如被 STOP SLAVE 过），或者主从时间不同步导致计算异常。
-
Slave_IO_Running: Yes和Slave_SQL_Running: Yes必须同时为Yes，才说明复制链路通 - 如果
Master_Host是域名，注意 DNS 解析失败会导致 IO 线程中断，Seconds_Behind_Master就会停更 - MySQL 8.0.22+ 支持
performance_schema.replication_applier_status_by_coordinator查更细粒度的并行复制进度，但日常诊断还是优先用SHOW SLAVE STATUS
mysqlbinlog 能不能直接解析从库 relay log 来确认执行点
能，但不推荐直接解析 relay log。relay log 是从库自己生成的二进制格式文件，名字类似 relay-bin.000001，位置在 relay_log 配置项指定的路径下（默认和 data dir 同目录）。mysqlbinlog 可以读它，但要注意：
- 必须用和从库**完全一致版本**的
mysqlbinlog，否则可能解析失败或跳过事件 - relay log 里的
server_id是主库的，不是从库的，别靠它反推来源 - 解析结果里看到的
end_log_pos是 relay log 自身偏移，不是主库 binlog 的原始位置；要对齐主库进度，得结合SHOW SLAVE STATUS中的Relay_Master_Log_File+Exec_Master_Log_Pos - 线上从库一般开启
relay_log_recovery=ON，重启后会自动重建 relay log，旧文件可能已被轮转删除
为什么 mysqlbinlog 解析主库 binlog 看到的位点，和从库显示的不一致
因为主库 binlog 和从库执行点之间存在“事件转换”和“过滤”：GTID 模式下会跳过已执行事务；replicate_ignore_db 或 replicate_do_table 会让部分事件根本不写入 relay log；还有半同步复制中未确认的事务，主库 binlog 已写但从库还没收到。
典型场景：主库执行了 INSERT INTO test.t1，但从库配置了 replicate_ignore_db=test，那么这条语句根本不会出现在 relay log 里，Exec_Master_Log_Pos 就不会推进——但你在主库 mysqlbinlog mysql-bin.000001 里肯定能看到它。
- 检查过滤规则：看从库配置文件或
SHOW VARIABLES LIKE '%replicate%' - GTID 复制下，用
SELECT * FROM performance_schema.replication_applier_status_by_worker查每个 worker 的LAST_SEEN_TRANSACTION，比位点更准 - 如果主库开了
binlog_row_image=MINIMAL，mysqlbinlog解析出的 ROW event 可能缺少完整列，容易误判影响范围
实时监控同步延迟，有没有比 SHOW SLAVE STATUS 更轻量的方法
有，但得接受精度折衷。pt-heartbeat 是最成熟的选择：它在主库定时写一个带时间戳的记录到专用表，从库查这个表算差值。不依赖 MySQL 内部状态，也不受 Seconds_Behind_Master 的各种假阳性干扰。
注意：它测的是“数据新鲜度”，不是复制线程状态。如果 SQL 线程挂了，pt-heartbeat 依然会返回一个越来越大的延迟值；而 SHOW SLAVE STATUS 会立刻暴露 Slave_SQL_Running: No。
- 部署时必须确保主从都启用
READ_COMMITTED或更高隔离级别，否则从库可能读到未提交的 heartbeat 记录 - 不要把 heartbeat 表放在
mysql系统库下，某些备份工具会跳过它 - 监控脚本里别只看延迟数值，一定要同时检查
pt-heartbeat的退出码和 stderr 输出——超时或连接失败时它可能返回 0 但实际没更新
真正难的不是查进度，而是判断“这个进度是不是可信的”。比如 GTID 模式下 Exec_Master_Log_Pos 已失效，但很多人还在盯它；又比如 relay log 刚被 purge，mysqlbinlog 就找不到对应文件。这些边界情况，比命令本身更需要经验去交叉验证。
