必须将slave_parallel_type设为LOGICAL_CLOCK并配合主库组提交才能使slave_parallel_workers生效；默认DATABASE模式下单库写入仍串行，且需STOP/START SLAVE重启SQL线程，主库binlog_format须为ROW。
MySQL 5.7 主从延迟高，单纯调大 slave_parallel_workers 往往无效，甚至可能让延迟更严重——因为默认的单线程 SQL 线程模型下，该参数根本不会生效。
为什么 slave_parallel_workers 在 5.7 里经常“不工作”
MySQL 5.7 引入了并行复制能力，但它的启用有严格前提：必须开启基于库（database）或基于组提交（LOGICAL_CLOCK）的并行调度策略。而默认配置下，slave_parallel_type 是 DATABASE，且仅当主库写入涉及多个数据库时，才会触发多线程分发；如果所有业务表都在同一个库（比如 app_db），那即使设了 slave_parallel_workers=8，SQL 线程也只会用 1 个 worker 处理全部事务。
-
slave_parallel_type必须显式设为LOGICAL_CLOCK才能按事务组并行（依赖主库binlog_group_commit_sync_delay和binlog_group_commit_sync_no_delay_count配合） -
slave_parallel_workers值大于 0 仅表示“允许启用”，不代表“自动启用”——它受slave_parallel_type和主库实际 binlog 组提交行为共同制约 - 若主库
binlog_format是STATEMENT，且存在非确定性函数（如NOW()、UUID()），会导致事务无法安全并行，降级回单线程
检查并行复制是否真正在运行
不能只看 SHOW SLAVE STATUS\G 里的 Slave_SQL_Running_State 是否写着 “Reading event from the relay log”。要确认并行是否生效，得查这两个关键指标：
- 执行
SELECT * FROM performance_schema.replication_applier_status_by_worker;—— 如果WORKER_ID只有 1 行且THREAD_ID非 NULL，说明仍在单线程模式 - 观察
Seconds_Behind_Master下降趋势是否变快；更可靠的是对比relay_log_space增长速率和Exec_master_log_pos推进速度，看是否有多个位置在并发追平 - 注意：若
Replicate_Wild_Do_Table或replicate-do-db配置了单库过滤，slave_parallel_type=DATABASE就彻底失效
启用 LOGICAL_CLOCK 并行前必须做的三件事
跳过这三步直接改参数，大概率导致 SQL 线程启动失败或复制中断：
- 主库必须开启
binlog_transaction_dependency_tracking = WRITESET（推荐）或COMMIT_ORDER，否则从库无法识别事务依赖关系 - 主库
binlog_format必须为ROW——STATEMENT或MIXED下WRITESET不起作用 - 从库需提前执行
STOP SLAVE; SET GLOBAL slave_parallel_type='LOGICAL_CLOCK'; SET GLOBAL slave_parallel_workers=4;，再START SLAVE；不能热更新slave_parallel_type
为什么你看到延迟没降反升？
常见于以下真实场景：
- 主库刚执行完一个耗时 20 秒的
DELETE FROM huge_table WHERE ...，这个事务会独占一个 worker，其他 worker 空转等待，Seconds_Behind_Master暂停增长但实际延迟在累积 - 从库磁盘 I/O 已饱和（
iostat -x 1显示 %util >95），加再多 worker 也只是排队等 IO，反而因上下文切换加重 CPU 开销 - 从库
innodb_buffer_pool_size过小，大量页需要从磁盘读取，worker 线程频繁阻塞在 Buffer Pool miss 上 - 误将
slave_parallel_workers设得过大（如 16），超出从库 CPU 核心数，线程争抢加剧，吞吐不增反降
真正卡点往往不在复制线程本身，而在从库的 IO 能力和内存配置。别急着调并行数，先用 fio 测磁盘随机写 IOPS，用 SHOW ENGINE INNODB STATUS\G 看 buffer pool hit rate —— 这些比改 slave_parallel_workers 更决定延迟上限。
