主从延迟的根本原因是SQL线程单线程回放relay log；开启并行复制、拆分大事务、优化硬件与参数可有效降低延迟。
主从延迟的根本原因：复制线程单点瓶颈
MySQL 主从延迟（Replication Lag）最常见根源在于从库的 SQL 线程（即 SQL Thread）是单线程回放 relay log 的。即使主库并发写入很高，从库也只能顺序执行事务，尤其遇到大事务、DDL、长更新或锁竞争时，延迟会快速堆积。
关键点：
– IO Thread 只负责拉取 binlog，通常不构成瓶颈；
– 真正卡住的是 SQL Thread 单线程重放逻辑；
– 延迟值（Seconds_Behind_Master）反映的是 SQL Thread 落后主库的时间，不是网络或 IO 问题。
开启并行复制：让多个线程协同回放
MySQL 5.6 引入了基于库（database）的并行复制，5.7 支持基于逻辑时钟（MTS，Multi-Threaded Slave），8.0 默认启用增强型 MTS（writeset-based）。启用并行复制可显著降低延迟，但需合理配置：
- 设置并行工作线程数：调整 slave_parallel_workers（如设为 4 或 8），数值建议 ≤ CPU 核心数 × 1.5；
-
选择并行调度策略：
- 5.7+ 推荐 slave_parallel_type = LOGICAL_CLOCK（默认），按事务 commit_order 并行；
- 8.0+ 更推荐 slave_parallel_type = LOGICAL_CLOCK + binlog_transaction_dependency_tracking = WRITESET，利用 writeset 判断事务间无冲突，提升并发粒度；
- 确保主库开启 GTID：GTID 模式下并行复制更稳定，避免 position 错位风险；
- 检查从库 relay log 格式：必须为 ROW 格式（binlog_format=ROW），STATEMENT 或 MIXED 不支持 writeset 依赖追踪。
减少单事务压力：拆分大操作与优化写法
并行复制无法加速单个大事务——它仍由一个 worker 独占执行。因此必须从源头控制事务粒度：
- 批量 INSERT/UPDATE/DELETE 分批次提交，每批 ≤ 1000～5000 行，避免单事务执行超 1 秒；
- 避免在事务中执行耗时操作（如调用 UDF、访问外部服务、大字段 LOB 写入）；
- DDL 操作（如 ALTER TABLE）尽量在低峰期执行，并考虑使用 pt-online-schema-change 或 MySQL 8.0 的 INSTANT/ALGORITHM=INPLACE；
- 监控 SHOW PROCESSLIST 中长时间运行的 System lock 或 Waiting for table metadata lock，定位阻塞源。
辅助优化手段：硬件、参数与可观测性
并行复制不是银弹，还需配合系统级调优和持续观测：
- 从库硬件升级：优先提升磁盘 IOPS（SSD）、内存（缓冲 relay log 和 buffer pool）、CPU 核心数；
-
关键参数微调：
- relay_log_recovery = ON（崩溃恢复更可靠）；
- sync_relay_log = 1（防止 relay log 丢失，代价略增 IO）；
- slave_preserve_commit_order = ON（MTS 下保持事务提交顺序，避免从库一致性异常）；
- 实时监控延迟指标：除 Seconds_Behind_Master 外，关注 Retrieved_Gtid_Set 与 Executed_Gtid_Set 差值、Slave_SQL_Running_State（是否卡在某类状态）、以及 per-worker 的 performance_schema.replication_applier_status_by_worker 表；
- 定期清理 relay log：启用 relay_log_purge = ON，避免磁盘打满导致复制中断。
