mysql 5.7并行复制需同时配置slave_parallel_type=logical_clock和slave_parallel_workers>0才生效，仅设workers无效；默认database模式不支持单库并行。
MySQL 5.7 并行复制不能只靠 slave_parallel_workers 就生效 —— 它必须和 slave_parallel_type 配合使用，且默认值是 DATABASE（无效于单库场景），slave_parallel_workers=0 时直接退化为单线程。
为什么 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 都不会真正并发。
-
slave_parallel_type = DATABASE：每个库独占一个 worker，多表单库=零并行 -
slave_parallel_type = LOGICAL_CLOCK：基于 binlog 的last_committed分组，同一组内事务可并行（支持单库多表） - 必须先设
LOGICAL_CLOCK，再设slave_parallel_workers > 0，顺序不能反
在线开启并行复制的最小安全操作集
无需重启 MySQL，但必须停掉 SQL 线程后再改参数，否则部分变量会拒绝修改（如 slave_parallel_type）。
STOP SLAVE SQL_THREAD;SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK';-
SET GLOBAL slave_parallel_workers = 4;（建议 2~8，别盲目设 16；worker 过多反而因调度开销拖慢） -
SET GLOBAL slave_preserve_commit_order = ON;（关键！否则并行回放可能破坏事务提交顺序） START SLAVE SQL_THREAD;
验证是否生效：SHOW SLAVE STATUS\G 中检查 Slave_SQL_Running_State 是否出现 Waiting for an event from Coordinator（说明 worker 已就位）；同时查 performance_schema.replication_applier_status_by_worker 表，应有对应数量的非空记录。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
master_info_repository 和 relay_log_info_repository 必须设为 TABLE
这两个参数若保持默认 FILE，在多线程复制下会引发严重性能问题：多个 worker 线程频繁争抢更新 master.info 和 relay-log.info 文件，导致 I/O 瓶颈甚至元数据不一致。
SET GLOBAL master_info_repository = 'TABLE';SET GLOBAL relay_log_info_repository = 'TABLE';- 执行后原
master.info、relay-log.info文件会被自动删除，信息转存至mysql.slave_master_info和mysql.slave_relay_log_info表 - 该变更需配合
relay_log_recovery = ON（防止 crash 后 relay log 位置错乱）
注意：这两个 SET GLOBAL 命令本身可在线执行，但某些旧版本（如 5.7.10 之前）要求重启才生效，稳妥起见建议写入从库配置文件 my.cnf 并重启。
容易被忽略的兼容性与监控盲区
即使所有参数都配对了，也未必真能跑出预期并行度 —— 关键取决于主库 binlog 的组提交质量。
- 主库必须开启
binlog_format = ROW，且推荐binlog_row_image = FULL（避免部分更新导致从库解析失败） - 主库
binlog_group_commit_sync_delay和binlog_group_commit_sync_no_delay_count影响last_committed分组密度；组越密，并行机会越多 -
performance_schema.replication_applier_status_by_worker是唯一可信的实时 worker 负载视图，别只看Seconds_Behind_Master - 若主库写入高度串行（例如大量单事务+显式
COMMIT），last_committed几乎全不同，worker 实际仍串行回放
真正决定并行效率的，从来不是你设了多少个 slave_parallel_workers，而是主库有没有产生足够多的“可并行事务组”。调参只是铺路，源头优化才是关键。
