MySQL 5.7并行复制需同时满足主库binlog_format=ROW、binlog_transaction_dependency_tracking=WRITESET，从库slave_parallel_type=LOGICAL_CLOCK、slave_parallel_workers>0、slave_preserve_commit_order=ON及master_info_repository=TABLE等条件，缺一不可。
MySQL 5.7 的并行复制不是设了 slave_parallel_workers 就能自动加速的——它必须同时满足主库写法、从库参数、元数据存储方式三方面条件，缺一不可。
为什么 set global slave_parallel_workers = 4 没效果？
常见错误现象：执行了 SET GLOBAL slave_parallel_workers = 4，但 SHOW SLAVE STATUS\G 中仍显示 SQL_Thread_Running: Yes（单线程标识），Seconds_Behind_Master 毫无改善。
-
slave_parallel_workers只控制 worker 数量，不决定是否并行；真正起作用的是slave_parallel_type - 默认值是
DATABASE，意味着只按库分发事务——如果主库所有写都在同一个库（比如app_db），那无论设多少 workers，实际只有 1 个在干活 -
slave_parallel_type = LOGICAL_CLOCK才支持单库内多表事务并行，但该变量不能在线动态修改，必须先停 SQL 线程
必须同步调整的主库配置
并行复制依赖主库 binlog 中的 last_committed 和 sequence_number 字段，它们只在特定配置下生成。
-
binlog_format必须为ROW（MIXED或STATEMENT不产生组提交信息） -
binlog_transaction_dependency_tracking必须设为WRITESET（比默认的COMMIT_ORDER更细粒度，支持跨表并行） - 检查命令：
SELECT @@binlog_format, @@binlog_transaction_dependency_tracking; - 若不满足，需在主库修改配置并重启，或（5.7.20+）用
SET GLOBAL动态设置
从库启用 LOGICAL_CLOCK 的最小安全操作集
不能只改 slave_parallel_workers，必须按顺序执行以下操作，否则参数无效或被静默忽略。
- 先执行
STOP SLAVE SQL_THREAD;（仅停 SQL 线程，IO 线程可保持运行） - 再设
SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK';（注意大小写，'LOGICAL_CLOCK'不能写成小写或驼峰） - 然后设
SET GLOBAL slave_parallel_workers = 4;（建议 2～8，设 16 反而因调度开销拖慢） - 必须设
SET GLOBAL slave_preserve_commit_order = ON;（否则并行回放会破坏事务提交顺序，导致数据不一致） - 最后
START SLAVE SQL_THREAD;
master_info_repository 和 relay_log_info_repository 必须为 TABLE
这两个参数若保持默认 FILE，在多线程复制下会引发严重 I/O 瓶颈：多个 worker 线程争抢更新 master.info 和 relay-log.info 文件，甚至导致元数据不一致。
- 执行
SET GLOBAL master_info_repository = 'TABLE'; - 执行
SET GLOBAL relay_log_info_repository = 'TABLE'; - 执行后原
master.info、relay-log.info文件会被自动删除 - 该操作无需重启，但必须在开启并行复制前完成
最容易被忽略的是 slave_preserve_commit_order = ON 和元数据存储方式——它们不直接影响“是否启动多线程”，却直接决定“多线程是否安全可用”。一旦漏掉，要么数据错乱，要么性能不升反降。
