MySQL 5.7多线程复制需同时满足三条件才生效：slave_parallel_type=LOGICAL_CLOCK、binlog_format=ROW、所有表有主键；仅设slave_parallel_workers无效，否则仍单线程回放。
MySQL 5.7 的多线程复制不是设了 slave_parallel_workers 就能跑起来的——必须同时满足三个硬性条件，缺一不可，否则你看到的仍是单线程回放。
为什么 slave_parallel_workers 设了却没效果？
这是最常见误判：以为只要调大这个值，SQL 线程就会自动并发。实际上它只是“工人数量”，而调度器（coordinator）根本没启用。
-
slave_parallel_type必须显式设为'LOGICAL_CLOCK'；设成'DATABASE'或保持默认OFF，slave_parallel_workers再大也只用 1 个 worker -
binlog_format必须是ROW；如果是MIXED或STATEMENT，LOGICAL_CLOCK 模式会静默退化为单线程 - 从库不能有无主键表；
Error_code: 1032报错大概率源于此，一旦触发，并行复制立即中止，回退到单线程重试
如何确认并行复制真正启动？
别只看 Seconds_Behind_Master 是否下降——它可能卡在 0 却没提交，也可能因时钟偏差失真。要看真实运行态：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 执行
SHOW SLAVE STATUS\G，重点盯Slave_SQL_Running_State：若长期显示Reading event from the relay log，说明 coordinator 根本没分发任务，还是单线程读 relay log - 查
SELECT * FROM performance_schema.replication_applier_status_by_worker;：只有WORKER_ID = 1在ONLINE，其余全OFFLINE→ 并行未生效 - 确认
slave_parallel_type和binlog_format已全局生效：SHOW VARIABLES LIKE 'slave_parallel_type';和SHOW VARIABLES LIKE 'binlog_format';
配置必须写进 my.cnf，不能只靠 SET GLOBAL
RDS 或部分生产环境会锁定动态变量，SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK' 直接报 ERROR 1238: Variable is a read only variable 是常态。
- 阿里云 RDS：必须在控制台「参数模板」中修改，且多数需重启实例才生效
- 腾讯云 CDB / AWS RDS MySQL 8.0：
slave_parallel_type通常默认已开，但slave_parallel_workers默认为 0，需手动调高 - 自建 MySQL：仍建议写入
my.cnf的[mysqld]段，避免重启后丢失；改完执行mysql> STOP SLAVE; START SLAVE;才真正加载
worker 数量不是越多越好，得看从库 CPU 核数
设 slave_parallel_workers = 16 却只有 4 核 CPU，只会加剧线程争抢和上下文切换开销，实际吞吐反而下降。
- 推荐初始值设为从库逻辑 CPU 核数的 70%～80%，例如 8 核机器设为 6～7
- 观察
performance_schema.replication_applier_status_by_worker中各 worker 的LAST_APPLIED_TRANSACTION进度是否均衡；严重不均说明事务粒度或分组不合理，可能受跨库 DML 或大事务拖累 - 注意：大事务（如单事务更新 50 万行）仍会被整个塞进一个 worker，无法拆分——并行复制解决的是“事务间”并发，不是“事务内”并发
真正难的从来不是配参数，而是验证每张表都有主键、确认 binlog_format 没被应用层悄悄切回 STATEMENT、以及区分清楚“延迟为 0”到底是同步完成，还是 SQL 线程正卡在 Committing event 里不动。
