mysql并行复制需满足多条件：slave_parallel_workers仅是线程数，实际并行依赖slave_parallel_type策略（database级单库无效，logical_clock需gtid+主库group commit），且需重启sql线程生效；seconds_behind_master为表象，真实延迟需结合relay_log_space、read/exec_master_log_pos差值及replication_applier_status_by_worker排查；net_*_timeout仅防io重连，降延迟核心在主库事务拆分、从库i/o优化（ssd/innodb_flush_log_at_trx_commit=2）及gtid正确启用。
为什么 slave_parallel_workers 设了还是不并行？
MySQL 并行复制不是设了 slave_parallel_workers 就自动生效的，它依赖底层的并行策略。5.7 默认用的是 DATABASE 级并行（slave_parallel_type = DATABASE），这意味着只有跨库的 DML 才能并行；如果所有写都在同一个库，哪怕开了 8 个 worker，实际还是串行回放。
- 检查当前策略：
SHOW VARIABLES LIKE 'slave_parallel_type';，若为DATABASE，单库场景下基本无效 - 改成
LOGICAL_CLOCK（需开启 GTID）：SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK';，它基于 group commit 和last_committed判断事务可并行性 - 确认主库已启用
binlog_group_commit_sync_delay和binlog_group_commit_sync_no_delay_count，否则主库压根不打包提交，从库就收不到可并行的事务组 - 注意：切换后需重启 SQL 线程，或先
STOP SLAVE; START SLAVE;，仅改变量不触发重载
Seconds_Behind_Master 一直卡在 0 却实际延迟很高？
这个值只反映 relay log 最后一个事务的执行时间与当前系统时间差，但掩盖了两个关键问题：SQL 线程正在执行一个超长事务（比如大表 UPDATE），或者 IO 线程拉取慢但还没积压到 relay log 文件层面（比如网络卡顿导致 Master_Host 连接时断时续）。
- 看真实状态优先用：
SHOW SLAVE STATUS\G中的Seconds_Behind_Master、Read_Master_Log_Pos和Exec_Master_Log_Pos差值，再结合Relay_Log_Space是否持续增长 - 查正在执行的 SQL：
SELECT * FROM performance_schema.replication_applier_status_by_worker;，重点关注LAST_SEEN_TRANSACTION和WORKER_ID对应的LAST_ERROR_MESSAGE - 如果
Read_Master_Log_Pos长时间不动，问题在 IO 层——检查主从间网络丢包、防火墙限速、主库max_allowed_packet是否被从库连不上时静默截断
调大 net_read_timeout 和 net_write_timeout 真的有用吗？
有用，但只解决“连接中断”这类表层症状，不是延迟根源。这两个参数控制从库读/写 socket 的等待上限，默认 30 秒。当主从间存在高延迟、弱网络（如跨机房专线抖动），IO 线程可能频繁因超时断开重连，导致 binlog 拉取断续、relay log 积压。
- 建议值：从库端设为
net_read_timeout = 60、net_write_timeout = 60，避免小抖动引发重连风暴 - 必须同步调大主库的
wait_timeout和interactive_timeout（至少 ≥ 60），否则主库主动踢掉空闲连接，从库重连时会报Lost connection to MySQL server during query - 注意：
net_*_timeout不影响 SQL 回放速度，只是让 IO 更“耐烦”；真要降延迟，得靠并行 + 主库 group commit + 从库硬件 I/O 能力
主库写入快，但从库磁盘 I/O 上不去，是瓶颈在哪？
常见误区是以为“从库 CPU 低、I/O 利用率低=没压力”，其实 MySQL 从库 SQL 线程是单线程（即使开了并行，worker 也受限于 relay log 解析和 InnoDB 行锁争用）。真正卡点常在：relay log 写入、InnoDB redo 日志刷盘、二级索引维护、甚至 innodb_flush_log_at_trx_commit = 1 强制刷盘带来的顺序 I/O 压力。
- 用
iostat -x 1观察%util和await，若await> 20ms 且%util接近 100%，说明磁盘响应慢，优先考虑 SSD 或调整刷盘策略 - 临时缓解：从库设
innodb_flush_log_at_trx_commit = 2（牺牲一点安全性换性能），同时确保sync_binlog = 0（binlog 不强制刷盘） - 更治本：把大事务拆小（主库避免
UPDATE t1 SET ... WHERE id BETWEEN 1 AND 1000000），减少单次回放锁表时间和 redo 写入量
并行复制效果高度依赖主库事务分组质量，网络优化只是保底手段；最容易被忽略的是主库未开启 GTID 就强行切 LOGICAL_CLOCK，结果并行直接失效——得先 SET GLOBAL gtid_mode = ON_PERMISSIVE; 一步步升到 ON，不能跳步。
