主从延迟怎么看：先确认是不是真延迟
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 线程彻底卡死。
