使用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 模式下）
如果启用了 GTID 复制，可以通过比较主从的 GTID 集合来判断延迟：主库上执行：
SELECT @@GLOBAL.gtid_executed;
从库上执行：
SELECT @@GLOBAL.gtid_executed;
3. 使用 performance_schema 监控复制延迟（MySQL 5.7+）
MySQL 提供了 performance_schema 中的复制相关表，例如：SELECT * FROM performance_schema.replication_applier_status_by_worker;
可以查看每个 SQL 线程的工作进度和延迟情况，适用于多线程复制环境。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 或心跳表做补充验证，能更准确掌握复制延迟状态。
