slave_parallel_workers合理值为cpu核心数×0.7向上取整，如16核设12，须配合slave_parallel_type=logical_clock及主库binlog_transaction_dependency_tracking=writeset，并执行stop/start replica生效。
slave_parallel_workers 设置多少才合理
从库单线程回放是延迟的根源之一，slave_parallel_workers 必须大于 0 才能启用并行复制。设得太小（比如 2）压不住高并发写入；设得太大（比如超过 CPU 核心数）反而引发线程争抢、上下文切换开销上升。
- 建议值 =
ceil(CPU核心数 × 0.7)，例如 16 核服务器设为12 - 必须配合
slave_parallel_type=LOGICAL_CLOCK，否则并行无效 - 主库需开启
binlog_transaction_dependency_tracking=WRITESET，否则从库无法准确判断事务可并行性 - 修改后执行
STOP REPLICA; START REPLICA;生效，不能只 reload 配置
Seconds_Behind_Master 为什么有时显示 NULL 或 0 却仍有延迟
Seconds_Behind_Master 并非实时精确值，它依赖主库 binlog event 中的时间戳与从库系统时间对比。当 IO 线程中断、SQL 线程卡住或 relay log 切换时，该值会失真。
- IO 线程异常（
Slave_IO_Running: No）时，该值固定为NULL，实际延迟已不可见 - SQL 线程正在执行大事务，但尚未写入新 event，
Seconds_Behind_Master可能仍显示0，而真实延迟已在累积 - 更可靠的判断方式是比对
Exec_Master_Log_Pos和Read_Master_Log_Pos差值，再结合Relay_Log_Space是否持续增长 - MySQL 8.0+ 推荐用
performance_schema.replication_applier_status_by_worker查每个 worker 的 lag 秒数
大事务导致延迟飙升，但又不能拆分怎么办
DDL（如 ALTER TABLE）和批量 UPDATE/DELETE 几乎必然阻塞 SQL 线程，且无法拆分。硬扛只会让延迟滚雪球。
- 优先用
pt-online-schema-change或 MySQL 8.0+ 的ALGORITHM=INSTANT/ALGORITHM=INPLACE替代传统 DDL - 若必须用 blocking DDL，提前在从库执行
STOP REPLICA，等主库执行完再START REPLICA，避免同步队列被堵死 - 监控
information_schema.innodb_trx中TIME_TO_SEC(NOW() - trx_started) > 300的长事务，设置自动 kill 脚本 - 业务层控制：禁止前端触发单次影响行数超 10 万的写操作，改由后台任务分批处理
网络和磁盘 IO 是隐藏瓶颈，怎么快速定位
很多团队调了半天参数，结果发现是千兆网卡跑满、或者从库 SATA SSD 在随机写上吞吐只有 50 IOPS。
- 用
iperf -c 主库IP -t 60测实际带宽，低于 800Mbps 就要查交换机限速或网卡驱动 - 看
iostat -x 1中从库的%util是否长期 >90%，await是否 >20ms —— 这说明磁盘已成瓶颈 -
SHOW ENGINE INNODB STATUS\G里搜pending，如果log i/o pending或file i/o pending非零，就是 IO 卡住了 - 从库禁用
binlog（除非用于级联），关闭innodb_doublewrite（仅限 SSD 环境且接受风险）可减 IO 压力
真正卡住复制的，往往不是某个开关没开，而是硬件资源与业务负载不匹配——比如用 4 核 8GB 的云主机跑日均千万写入的从库，再怎么调 slave_parallel_workers 也撑不住。先看 iostat 和 top，再动配置。
