主从延迟需先确认是否真实：Seconds_Behind_Master持续>5秒且增长才属真延迟；排查需依次检查SQL线程状态、relay log追平情况、GTID并行复制配置、磁盘I/O性能及业务写法优化。
主从延迟超过秒级，先查 Seconds_Behind_Master 是否真延迟
很多情况下 Seconds_Behind_Master 显示非 0，但实际是误报：比如从库 SQL 线程空闲、IO 线程刚拉完日志还没开始执行，或主库无写入时该值可能抖动。真正要关注的是持续 > 5 秒且不断增长的延迟。
确认方式：
- 登录从库执行 SHOW SLAVE STATUS\G，重点看 Seconds_Behind_Master、SQL_Delay（是否人为设了延迟）、Slave_SQL_Running_State（如卡在 “Reading event from the relay log” 说明 SQL 线程慢）；
- 同时对比主从的 SHOW MASTER STATUS 和 SHOW RELAYLOG EVENTS，看 relay log 是否已追平 master log position。
常见误判点：
- 主库启用 binlog_format=STATEMENT 且含非确定函数（如 NOW()、UUID()），导致从库重放结果不一致，SQL 线程可能重试或卡住
- 从库开启了 read_only=1 但有 super 权限用户执行了写操作，破坏了复制一致性，触发校验失败后停同步
从库单线程回放瓶颈明显，考虑升级到基于 GTID 的并行复制
MySQL 5.6+ 默认 SQL 线程是单线程的，即使主库并发高，从库也只能串行执行 relay log 中的事务——这是延迟最常见根源。
开启并行复制的关键配置：
- slave_parallel_type=LOGICAL_CLOCK（推荐，比 DATABASE 更细粒度）
- slave_parallel_workers=4（建议设为 CPU 核数的 70%，避免上下文切换开销）
- 必须启用 GTID：gtid_mode=ON + enforce_gtid_consistency=ON
注意：
- 并行复制只对 binlog_format=ROW 有效，STATEMENT 模式下事务间依赖难判定，无法安全并行
- 如果主库存在大事务（如单个 UPDATE 影响百万行），它仍会独占一个 worker，拖慢整体进度
- 查看并行效果：监控 performance_schema.replication_applier_status_by_coordinator 表中的 WORKERS 数和 APPLYING_EVENT 状态
主库写入突增或从库 I/O 负载高，检查 relay log 刷盘与磁盘性能
relay log 写入慢、刷盘阻塞，会导致 IO 线程跟不上主库节奏，进而拖累整个复制链路。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
实操排查项：
- 检查从库 sync_relay_log=10000（默认值），值太小（如 1）会频繁 fsync，拖慢 IO 线程；太大（如 0）则宕机可能丢 relay log
- 确保 relay log 存放在独立、低延迟磁盘（避开系统盘或主库数据盘），用 relay_log=/data/mysql/relay-bin 显式指定路径
- 观察 iostat -x 1 中从库磁盘的 %util 和 await，若长期 >90% 或 await >20ms，说明磁盘已成瓶颈
- 避免在从库执行大查询：全表扫描、未走索引的 JOIN 会大量读取 buffer pool，挤占 IO 带宽，间接影响 relay log 读取速度
业务层写入不合理，直接放大复制压力
很多延迟问题根源不在 MySQL 配置，而在应用写法。例如批量插入用 1000 条 INSERT ... VALUES (...),(...),... 是高效的；但若拆成 1000 个单行 INSERT，就会产生 1000 个 binlog event，极大增加网络传输、解析、回放开销。
典型高危写法：
- 在循环中逐条 UPDATE 同一张表的多行（应改用 INSERT ... ON DUPLICATE KEY UPDATE 或临时表 JOIN）
- 使用 SELECT ... FOR UPDATE + 应用层判断再更新，导致锁等待传导到从库（从库虽不加锁，但事务顺序必须严格一致）
- 主库执行 ALTER TABLE 大表（尤其未用 ALGORITHM=INPLACE），会生成巨量 binlog，从库回放耗时极长
可落地优化：
- 对写密集场景，主库开启 binlog_row_image=MINIMAL（5.6.2+），减少 ROW 格式下 binlog 体积
- 从库设置 innodb_flush_log_at_trx_commit=2（牺牲极小安全性换回放速度，仅适用于非金融类场景）
- 关键业务表加 innodb_autoinc_lock_mode=2，避免自增锁阻塞主库并发插入
延迟不是孤立指标，它暴露的是主从链路中任意一环的短板：可能是主库日志生成太快，也可能是从库磁盘太慢，还可能是某条慢查询把 SQL 线程堵死了。定位时别只盯着 Seconds_Behind_Master，得顺着 IO 线程 → relay log → SQL 线程 → 应用写法这条链路一节节敲过去。
