MySQL主从延迟本质是SQL线程单线程回放跟不上主库并发写入，5.6及之前版本强制串行执行所有事件；5.7+需配置slave_parallel_workers>0且slave_parallel_type='LOGICAL_CLOCK'才能有效并行，同时须确保主库binlog_format=ROW、从库刷盘参数与硬件匹配。
MySQL主从延迟本质是SQL线程单线程回放
MySQL 5.6 及之前版本的 SQL thread 是纯单线程的：它必须串行重放主库 binlog 中的所有 DML 和 DDL 事件。哪怕主库是多核并发写入，从库也只能一条一条执行——这是延迟最根本的来源。
典型表现是：SHOW SLAVE STATUS\G 中 Seconds_Behind_Master 持续上涨，Slave_SQL_Running_State 长时间停留在 executing 或 updating 状态，且 Exec_Master_Log_Pos 明显落后于 Read_Master_Log_Pos。
- 大事务（如单个
UPDATE影响百万行）会让 SQL 线程卡住几十秒甚至几分钟 - 高频率小事务（如每秒数百次
INSERT）也会因单线程吞吐上限被击穿而积压 - 从库上存在慢查询、锁等待（如未加索引的
WHERE条件）会进一步拖慢回放节奏
MySQL 5.7+ 启用并行复制的关键配置项
并行复制不是开个开关就自动加速，必须显式设置两个核心参数，缺一不可：
-
slave_parallel_workers必须大于 0（默认是 0，即关闭并行）；建议设为 CPU 核心数的 1–2 倍，比如 4 或 8 -
slave_parallel_type决定并行粒度：'DATABASE'（按库分组，5.6–5.7 默认）或'LOGICAL_CLOCK'（按事务逻辑时钟分组，5.7+ 推荐）
配置过程必须停启复制：
STOP SLAVE; SET GLOBAL slave_parallel_workers = 4; SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK'; START SLAVE;
执行后检查：SHOW PROCESSLIST 应能看到多个 Worker 线程（如 Worker 1, Worker 2），而非仅一个 SQL Thread。
为什么 LOGICAL_CLOCK 比 DATABASE 更适合多数业务
slave_parallel_type = 'DATABASE' 要求不同库之间的事务完全无依赖，但现实中跨库 JOIN、外键、同名临时表等场景极易触发串行回退，实际并行度常为 1。
'LOGICAL_CLOCK' 基于 MySQL 5.7 引入的 last_committed 和 sequence_number 字段，只要主库事务提交时没有写冲突（即不修改同一行），就能在从库并行回放——这对大多数 OLTP 场景更友好。
- 主库需开启
binlog_order_commits=ON（默认开启），保证 binlog 写入顺序反映真实提交序 - 主库
binlog_format必须为ROW或MIXED，STATEMENT模式下last_committed不可靠 - 如果主库有大量
ALTER TABLE或全局锁操作，仍可能强制降级为单线程回放
容易被忽略的性能陷阱：刷盘参数与硬件不对等
即使开了并行复制，从库性能仍可能被底层 IO 卡住：
-
innodb_flush_log_at_trx_commit=1+sync_binlog=1是强一致性配置，但每次事务都刷盘，SSD 都扛不住高并发回放 - 从库用 SATA 盘、主库用 NVMe，或从库内存只有主库 1/2，
innodb_buffer_pool_size过小，会导致大量磁盘随机读 - 从库开启了
log_bin且设了sync_binlog=1，等于自己又当主库再刷一次盘，纯属自缚手脚
生产环境建议：从库关 binlog（skip_slave_start=OFF 不影响，但 log_bin=OFF 必须明确），或至少设 sync_binlog=0；innodb_flush_log_at_trx_commit 可设为 2（平衡安全性与速度）。
并行线程数不是越多越好——超过磁盘 IO 或 CPU 实际承载能力后，线程争抢反而降低吞吐。观察 SHOW ENGINE INNODB STATUS 中的 FILE I/O 和 BACKGROUND THREADS 区域，比盲目调高 slave_parallel_workers 更有效。
