MySQL主从延迟排查命令有哪些_利用show slave status查看日志

最直观但不可靠的延迟指标是Seconds_Behind_Master；真正可靠的是Read_Master_Log_Pos与Exec_Master_Log_Pos的差值；pt-heartbeat因绕过MySQL内部逻辑而更准确。

show sla ve status 输出里哪些字段直接反映延迟

说到主从延迟，很多人第一反应就是去看 Seconds_Behind_Master。这个指标确实直观，但千万别把它当成“金标准”。它完全有可能显示为 NULL 甚至是 0，而实际上从库已经落后了一大截。为什么会这样？原因可能包括IO线程没跑起来、SQL线程卡住了，或者在GTID模式下启用了 relay_log_recovery=ON 导致这个值不更新。

那么，真正靠得住的指标是什么？答案是直接对比两个位置信息：Read_Master_Log_Pos（从库已经读取到的主库binlog位置）和 Exec_Master_Log_Pos（从库已经执行到的主库binlog位置）。这两者之间的差值，才是实实在在的“积压量”，差值越大，说明延迟越严重。

在实际排查时，建议重点关注下面这几个字段的组合情况：

• Sla ve_IO_Running: Yes 且 Sla ve_SQL_Running: Yes —— 只有两个线程都跑着，延迟才能归咎于执行慢或者主库写入太快。
• Seconds_Behind_Master: NULL + Sla ve_SQL_Running_State: Waiting for dependent transaction to commit —— 这很可能是在并行复制（尤其是 sla ve_parallel_type=LOGICAL_CLOCK 模式下）被依赖事务给堵住了。
• Relay_Log_Space 持续暴涨 —— 这通常是个危险信号，意味着SQL线程消费Relay Log的速度，远远赶不上IO线程写入的速度，典型的执行瓶颈。

为什么 show sla ve status 看不到实时延迟？

你可能要问了，为什么 Seconds_Behind_Master 这么不靠谱？它的计算原理，是基于主库binlog事件里的 original_commit_timestamp 和从库当前的系统时间做对比。这里有个前提：主库必须开启了 binlog_transaction_dependency_tracking=COMMIT_ORDER（默认是开的），并且从库也得启用基于时间戳的依赖追踪。如果环境配置特殊，比如主库MySQL版本较老，或者设置了 master_info_repository=TABLE 和 relay_log_info_repository=TABLE，这个值就可能长期卡在 0 或 NULL，彻底失去参考意义。

所以，一个更稳妥的辅助判断方法是直接核对主从库的时间差：

• 在主库执行：SELECT UNIX_TIMESTAMP();
• 在从库执行：SELECT UNIX_TIMESTAMP(), @@read_only;（顺便确认下只读状态）
• 如果时间差大于1秒，并且 Exec_Master_Log_Pos 这个位置长时间不动，那基本可以断定是SQL线程挂住了。

用 pt-heartbeat 查延迟比 show sla ve status 更准吗？

答案是肯定的。pt-heartbeat 这个工具的思路很巧妙，它完全绕开了MySQL的内部状态逻辑。具体做法是在主库上定时插入一条带时间戳的记录，然后从库通过查询这条记录的时间差来反推复制延迟。这样一来，无论你是GTID模式、并行复制，还是用了特殊的binlog格式，都不会影响它的判断。更厉害的是，它能提供毫秒级的延迟数据，还能输出历史趋势、平均延迟、最大延迟等多个维度的信息。

不过，使用前有几点必须注意：

• 首先要在主库创建一个专用的heartbeat表（比如 CREATE TABLE heartbeat (ts TIMESTAMP NOT NULL PRIMARY KEY)），并确保从库有读取它的权限。
• 在主库启动更新进程，命令类似：pt-heartbeat --daemonize --update --user=root --password=xxx --host=master_ip --interval=1
• 查延迟时连接从库执行：pt-heartbeat --monitor --user=root --password=xxx --host=sla ve_ip --master-server-id=1 --interval=1
• 如果出现 pt-heartbeat 显示延迟很大，但 Seconds_Behind_Master 却显示为0的情况，那基本可以断定是MySQL自身的延迟统计机制失效了，而不是真的没有延迟。

除了 show sla ve status，还有哪些命令能定位延迟根源？

话说回来，单靠 SHOW SLA VE STATUS 只能告诉你“有没有延迟”，却回答不了“为什么延迟”。要挖出根本原因，还得配合其他命令进行交叉验证：

• 查SQL线程在干什么：执行 SHOW PROCESSLIST，找到 User=system user 且 Command=Query 的那一行，看看它的 State 是不是卡在 Updating、Sorting result，或者长时间处于 Waiting for table metadata lock。
• 查Relay Log的处理进度：用 SHOW RELAYLOG EVENTS IN 'relay-bin.000001' FROM 123456789 LIMIT 10; 这类命令，查看当前relay log的事件，对比 Exec_Master_Log_Pos，可以确认是否卡在某一条具体的SQL语句上。
• 查慢查询日志：先确认从库慢日志是否开启：SELECT @@slow_query_log, @@long_query_time;。如果开了，就去仔细检查慢日志文件，看看里面有没有复制应用线程执行的 INSERT/UPDATE 语句因为执行超时而被记录。
• 查磁盘I/O压力：在从库服务器上运行 iostat -x 1，重点观察 %util（利用率）和 await（等待时间）这两个指标。特别是存放relay log的磁盘（通常是 /var/lib/mysql/），如果这里成为瓶颈，复制速度肯定上不去。

实际上，真正拖住复制后腿的，往往是那些不那么起眼的问题：比如一条没加limit的大规模delete操作、复杂的锁等待，或者有人在从库上手动执行了一个长事务，导致元数据锁堆积。这些问题，都不会直接体现在 Seconds_Behind_Master 这个数字里，必须依靠 processlist 和慢日志这些工具，一层一层往下深挖才能找到症结。