设了slave_parallel_workers却没效果，90%是因为未切换至logical_clock模式或主库未配置row格式+writeset依赖追踪；必须stop slave后设slave_parallel_type='logical_clock'、slave_parallel_workers>1，并确认主库binlog_format=row且binlog_transaction_dependency_tracking=writeset，再start slave才生效。
直接结论：设了 slave_parallel_workers 却没效果，90% 是因为没切到 LOGICAL_CLOCK 模式，或主库没配 ROW 格式 + WRITESET 依赖追踪。
为什么 slave_parallel_workers 设了等于没设
MySQL 5.7+ 的并行复制不是“开个参数就自动多线程”，它分两层控制：
-
slave_parallel_type决定“能不能并行”——默认是DATABASE，只对跨库事务生效；单库多表（如所有表都在shop_db）下，哪怕设成 16，也只用 1 个 worker -
slave_parallel_workers决定“最多用几个线程”——但前提是slave_parallel_type已启用且主库满足并行条件 - 主库
binlog_format不是ROW、或没开binlog_transaction_dependency_tracking = WRITESET，从库会主动降级回单线程，slave_parallel_workers形同虚设
必须 STOP SLAVE 后再改参数
这两个变量都是只读的，动态 SET 会报错：ERROR 1238 (HY000): Variable 'slave_parallel_type' is a read only variable。实操顺序不能颠倒：
STOP SLAVE;SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK';-
SET GLOBAL slave_parallel_workers = 4;（建议从 2–4 起步，别直接设成 CPU 核数） START SLAVE;
改完立刻查：SHOW PROCESSLIST; 中应看到多个 system user 开头的线程；否则说明没生效。
怎么确认并行复制真正在跑
别只看 SHOW SLAVE STATUS\G 里的 Seconds_Behind_Master 是否下降——它可能波动，也可能被缓存误导。真正有效的验证方式是：
- 执行
SELECT * FROM performance_schema.replication_applier_status_by_worker;——如果只有WORKER_ID = 1行且THREAD_ID非 NULL，其余全为OFFLINE，说明仍在单线程 - 观察
WORKERS_PROCESSED列是否持续增长；若长期为 0 或极低，大概率是主库事务存在强依赖（比如无主键表、大事务、STATEMENT格式写入） - 查主库：
SELECT @@binlog_format, @@binlog_transaction_dependency_tracking;——必须是ROW+WRITESET
RDS 环境下特别注意的限制
阿里云/腾讯云/AWS RDS 并非所有实例都允许动态修改这些参数：
- 执行
SHOW VARIABLES LIKE 'slave_parallel%';，如果返回空或slave_parallel_type是OFF，先查版本：SELECT VERSION();—— 必须是 5.7.x 或 8.0.x - 尝试
SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK';，若报错 “read only variable”，说明需通过控制台「参数组」修改，并可能需要重启实例 - 部分低配 RDS 实例（尤其 5.6 或早期 5.7）默认锁定该参数，只能提交工单申请开通
最易被忽略的一点：哪怕 RDS 控制台显示参数已修改，也必须手动执行 START SLAVE; 才会真正加载新配置——很多人改完参数就以为完事了，其实 SQL 线程还在用旧模式跑。
