MySQL并行复制需同时配置slave_parallel_type=LOGICAL_CLOCK和slave_parallel_workers，仅设后者无效；主库须启用writeset依赖追踪，否则从库无法识别无冲突事务。
为什么 slave_parallel_workers 开了没效果
不是设了值就自动并行——MySQL 5.7+ 的并行复制依赖 slave_parallel_type = LOGICAL_CLOCK，默认是 DATABASE（按库分发），只要主库写的是同一个库，从库照样串行回放。
必须显式改成 LOGICAL_CLOCK 才能基于事务组提交（binlog_group_commit_sync_delay 配合）实现真正并行。
-
slave_parallel_type必须设为LOGICAL_CLOCK，不能只调slave_parallel_workers - 主库需开启
binlog_transaction_dependency_tracking = WRITESET（8.0.19+ 默认），否则从库无法精准识别事务间无冲突 - 从库
slave_parallel_workers建议设为 CPU 核数的 1.5～2 倍，但超过 16 后收益递减，且会增加线程调度开销
主库压力大，光调从库参数治标不治本
从库并行只能缓解“从库追不上”导致的延迟，但主库压力来源往往是高频小事务、大量 INSERT ... SELECT 或未优化的 binlog 写入。盲目提高 sync_binlog 或 innodb_flush_log_at_trx_commit 可能加剧 IO 压力。
- 确认主库瓶颈类型：用
SHOW PROCESSLIST看长事务，用perf top -p $(pgrep mysqld)看 CPU/IO 热点 - 避免在主库执行大事务；拆成小批次，或改到从库做报表类查询
- 如果主库磁盘 IO 高，检查
binlog_format是否为ROW（比STATEMENT写得多），但别轻易切回STATEMENT（有函数/临时表等兼容性风险）
并行复制下 Seconds_Behind_Master 不准怎么办
启用 LOGICAL_CLOCK 并行后，Seconds_Behind_Master 只反映最后一批事务的延迟，前面已分发但尚未完成的 worker 任务不计入——看起来延迟归零，实际可能积压了几十秒事务。
- 别只盯
Seconds_Behind_Master，用SHOW SLAVE STATUS\G查看Slave_SQL_Running_State和Exec_Master_Log_Pos变化趋势 - 监控
Performance Schema表：replication_applier_status_by_coordinator和replication_applier_status_by_worker，看各 worker 的LAST_APPLIED_TRANSACTION和APPLYING_TRANSACTION - 如果某个 worker 长期卡住（比如在执行 DDL），整个并行队列会被阻塞，此时需人工干预或跳过该事务（慎用
SET GLOBAL sql_slave_skip_counter = 1）
从库开启并行后出现主从数据不一致
并行本身不会导致不一致，但会放大已有隐患：比如主库用了非确定性函数（NOW()、UUID()）、或事务中混合了 DML 和 DDL（DDL 会强制刷空所有 worker 队列，破坏顺序）。
- 主库禁止在事务中混用 DDL 和 DML；DDL 单独成事务，且避免在高峰期执行
- 对时间敏感的字段，主库统一用
DEFAULT CURRENT_TIMESTAMP而非NOW()函数调用 - 上线前用
pt-table-checksum对比主从数据一致性，尤其关注含自增、触发器、外键的表
slave_parallel_workers”当成万能解药。真正卡点往往藏在主库事务设计、binlog 写入节奏、以及 DDL 与 DML 的穿插方式里。 
