使用 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 STATUSG
重点关注以下字段：
- 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;
从库的 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 或心跳表做补充验证，能更准确掌握复制延迟状态。
