真实延迟需比对主从binlog位点或用pt-heartbeat测时间戳差；Seconds_Behind_Master为0不代表无延迟，持续大于60秒且缓慢上涨才需警觉，结合Relay_Master_Log_File与Exec_Master_Log_Pos差值及pt-heartbeat结果综合判断。
MySQL 复制延迟不能只看 Seconds_Behind_Master，它在大事务、SQL线程卡住、主库空闲等场景下常失真。真正可靠的判断方式是比对主从 binlog 位置，或借助 pt-heartbeat 打时间戳。
怎么看真实延迟有多大
Seconds_Behind_Master 显示为 0，不代表没延迟；显示几百秒，也可能只是瞬时抖动。关键要看数据是否已落盘、位点是否追平。
- 在主库执行：
SHOW MASTER STATUS，记下 File 和 Position - 在从库执行：
SHOW SLAVE STATUS\G，重点看 Relay_Master_Log_File 和 Exec_Master_Log_Pos - 若 Relay_Master_Log_File ≠ 主库 File，说明 relay log 还没拉到最新 binlog 文件
- 若文件名一致，再比对 Exec_Master_Log_Pos 与主库 Position 的差值（单位字节），差得越多，延迟越真实
- 更稳的做法：用
pt-heartbeat在主库写入带时间戳的记录，从库读取并计算差值，完全绕过 MySQL 内部状态偏差
为什么 SQL 线程总卡在 “Reading event from the relay log”
这不是卡死，而是回放跟不上写入节奏——本质是单线程瓶颈。尤其当主库批量更新未拆分、从库硬件弱、或存在未提交的大事务时，这种现象特别明显。
- 一个改 50 万行的 UPDATE，在从库必须串行执行完才能推进位点
- 从库开启
log_slave_updates做级联复制，会额外增加解析开销 -
innodb_flush_log_at_trx_commit=1+sync_binlog=1会加重磁盘 I/O 压力 - MySQL 5.7+ 可启用
slave_parallel_workers > 0，但需主库开启binlog_transaction_dependency_tracking=WRITESET才能生效
哪些操作容易拖慢从库回放
不是所有慢查询都来自业务读请求，很多“隐形杀手”藏在复制链路里。
- 主库执行未加 LIMIT 的
UPDATE/DELETE，上线前务必检查 - 主库 DDL（如
ALTER TABLE）触发 MDL 锁，从库 SQL 线程会等待元数据锁释放 - 从库跑报表类任务，出现全表扫描、大 JOIN、filesort，直接抢走 SQL 线程资源
- 从库配置远低于主库：CPU 核数少、内存小、用 HDD 而非 SSD、云盘 IOPS 不足
- 网络不稳定导致 IO 线程频繁重连，relay log 积压
日常监控该盯哪些指标
靠人工查 SHOW SLAVE STATUS 不现实，得建立自动化盯控机制。
- 基础字段必监控：
Slave_IO_Running、Slave_SQL_Running、Seconds_Behind_Master、Relay_Log_Space - 推荐搭配
performance_schema.replication_applier_status查看 SQL 线程实时状态 - 用脚本每 5 秒轮询一次，延迟超阈值（如 30 秒）自动发告警
- 生产环境建议部署
pt-heartbeat或接入 Prometheus + Grafana，可视化延迟趋势 - 定期分析从库慢日志，重点关注
system user身份执行的语句（即 SQL 线程回放内容）
