使用SHOW SLAVE STATUS查看Seconds_Behind_Master可直接获取从库延迟秒数，结合Slave_IO_Running和Slave_SQL_Running判断复制状态；2. GTID模式下通过比较主从gtid_executed集合差异判断延迟；3. MySQL 5.7+可用performance_schema.replication_applier_status_by_worker监控多线程复制延迟；4. 自定义心跳表通过时间戳差值精确测量实际延迟。优先使用Seconds_Behind_Maste

在 MySQL 主从复制环境中，查看复制延迟是监控数据同步状态的重要环节。可以通过以下几种方式来判断从库的延迟情况。

1. 使用 SHOW SLAVE STATUS 查看 Seconds_Behind_Master

SHOW SLAVE STATUS\G

• Seconds_Behind_Master：表示从库落后主库的秒数。这是最直接的延迟指标。
• Slave_IO_Running：应为 Yes，表示 I/O 线程正在运行，拉取主库的 binlog。
• Slave_SQL_Running：应为 Yes，表示 SQL 线程正在应用中继日志。
• Master_Log_File 和 Read_Master_Log_Pos：从库当前读取的主库 binlog 位置。
• Relay_Master_Log_File 和 Exec_Master_Log_Pos：从库已执行到主库 binlog 的位置。

当 Slave_IO_Running 或 Slave_SQL_Running 为 No 时，Seconds_Behind_Master 可能显示为 NULL。另外，如果主从之间网络中断或从库停止复制，该值可能不准确。

2. 对比 GTID 集合（GTID 模式下）

主库上执行：
SELECT @@GLOBAL.gtid_executed;

从库上执行：
SELECT @@GLOBAL.gtid_executed;

3. 使用 performance_schema 监控复制延迟（MySQL 5.7+）

SELECT * FROM performance_schema.replication_applier_status_by_worker;

4. 自定义心跳表监控（高精度方法）

CREATE TABLE heartbeat (ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP);
INSERT INTO heartbeat VALUES ();

SELECT UNIX_TIMESTAMP(NOW()) - UNIX_TIMESTAMP(ts) AS delay FROM heartbeat;

基本上就这些常用方法。日常运维中，优先看 Seconds_Behind_Master，结合 GTID 或心跳表做补充验证，能更准确掌握复制延迟状态。