真实主从延迟需用时间戳打点或GTID比对：主库写入时间戳后查从库差值，或对比gtid_executed与Retrieved/Executed_Gtid_Set；Seconds_Behind_Master常失真。
主从延迟怎么看：先确认是不是真延迟
MySQL 主从延迟不是靠 SHOW SLAVE STATUS 里 Seconds_Behind_Master 一眼就能信的。这个值在从库 IO 线程没拉到最新 binlog、SQL 线程卡住、甚至主库时钟漂移时都会失真。更可靠的方式是用 GTID 或时间戳打点：
- 在主库执行：
SELECT UNIX_TIMESTAMP(); INSERT INTO test.heartbeat(ts) VALUES (UNIX_TIMESTAMP()); - 立即查从库该记录的
ts值，再执行一次SELECT UNIX_TIMESTAMP()，差值才是真实延迟 - 如果用 GTID，对比主库
SELECT @@global.gtid_executed;和从库Retrieved_Gtid_Set、Executed_Gtid_Set的差异范围
常见误判场景：
- 主库 NTP 时间不准，导致 Seconds_Behind_Master 显示负数或跳变
- 从库 SQL 线程因唯一键冲突、DDL 阻塞、大事务回滚而停在某条语句上，但 Seconds_Behind_Master 仍为 0
- 使用了 LOG_SLAVE_UPDATES=OFF 的级联从库，Seconds_Behind_Master 不反映上游延迟
写入放大类延迟：主库批量操作引发从库堆积
大事务、大批量 INSERT ... SELECT、UPDATE 全表扫描更新，在从库会串行重放（尤其 MySQL 5.7 及以前），极易造成秒级甚至小时级延迟。
缓解方式：
- 主库拆分大事务：把 UPDATE t SET status=1 WHERE create_time 改成按主键 ID 分页更新，每次 5000 行 + <code>SLEEP(0.1)
- 从库开启并行复制（需满足条件）：
- MySQL 5.7+：设置 slave_parallel_type = LOGICAL_CLOCK + slave_parallel_workers = 4~8
- MySQL 8.0+：推荐 slave_parallel_type = DATABASE（库级并行）或 LOGICAL_CLOCK（组提交并行），但要求主库 binlog_transaction_dependency_tracking = WRITESET
- 避免在主库执行 ALTER TABLE，改用 pt-online-schema-change 或 gh-ost，它们生成的小事务对从库更友好
从库性能瓶颈：硬件和配置拖慢 SQL 线程
从库延迟常被当成“同步问题”，其实一半以上是自身资源不足：磁盘 IOPS 不足导致 relay log 写入慢、buffer pool 太小引发频繁刷脏、CPU 单核跑满（SQL 线程默认单线程）。
检查与调优项：
- iostat -x 1 看从库 %util 是否持续 >90%，await 是否 >20ms；SSD 比 HDD 更适合从库
- 调大 innodb_buffer_pool_size（建议设为物理内存 60%~75%，但别超 80%）
- 关闭从库非必要功能：设 skip_log_bin=ON、innodb_flush_log_at_trx_commit=2、sync_binlog=0（仅限从库）
- 禁用从库查询缓存（query_cache_type=0），它在高并发下反而成为锁热点
网络与协议层延迟：跨机房/云厂商同步不稳定
主从跨地域（如北京主库 → 广州从库）、走公网、中间有防火墙或 NAT 设备时，TCP 重传率上升、RTT 波动大，relay log 传输卡顿，表现为 Slave_IO_Running: Yes 但 Seconds_Behind_Master 持续增长。
应对策略：
- 强制使用压缩协议：主库设 slave_compressed_protocol=ON，减少带宽占用（尤其文本型大字段）
- 调整 TCP 参数：从库服务器增加 net.ipv4.tcp_slow_start_after_idle = 0，避免长连接空闲后降速
- 检查 SHOW PROCESSLIST 中 IO 线程状态，若长期处于 Waiting for master to send event，说明网络收包慢；若卡在 Queueing master event to the relay log，则是磁盘写 relay log 慢
- 云环境优先选内网互通（如阿里云同可用区 VPC、AWS 同 AZ），避免跨 Region 直连
真实延迟优化从来不是调一两个参数就完事。最常被忽略的是：主库的慢查询日志里藏着大量未加索引的 UPDATE，它们在从库放大成延迟；还有 DBA 习惯性给从库开 read_only=OFF，结果应用误写从库触发死锁或隐式 DDL，让 SQL 线程彻底卡死。
