应查SHOW PROCESSLIST中Slave_worker线程数确认实际运行线程数，而非仅看slave_parallel_workers变量值；该变量仅反映配置，真正并行需STOP SLAVE; SET GLOBAL slave_parallel_workers=N; START SLAVE;后观察多个Slave_worker线程处于Waiting for an event from Coordinator状态才算生效。
怎么看当前从库用了几个并行复制线程
直接查 slave_parallel_workers 变量就行：SHOW VARIABLES LIKE 'slave_parallel_workers';
返回值是 0 表示没开并行复制，是正整数（比如 4、8、16）才是启用状态。这个值只反映配置，不代表当前活跃线程数。
真正运行中的线程数得看 SHOW PROCESSLIST; 输出里带 system user 和 Slave_worker 状态的行数——每个 Slave_worker 就是一个正在干活的并行 SQL 线程。
设多少合适：别盲目填 CPU 核数
常见误区是直接设成 slave_parallel_workers = $(nproc)。实际要综合三点：
-
slave_parallel_type必须是logical_clock，否则即使设了 >0 也只用 1 个线程（DATABASE模式下多库才有效） - 主库的
binlog_group_commit_sync_delay和binlog_group_commit_sync_no_delay_count影响事务分组效果，组太少，并行度就上不去 - 从库磁盘 I/O 和 relay log 解析能力是瓶颈：设太高反而导致线程争抢资源，
Seconds_Behind_Master波动变大
建议起步值设为 4 或 8，压测时观察 Performance_schema.replication_applier_status_by_worker 表里的 LAST_SEEN_TRANSACTION 和 WORKING_ON 字段分布是否均衡。
为什么改了 slave_parallel_workers 没生效
这个变量是动态的，但有前提：
- 必须先停复制：
STOP SLAVE; - 再设值：
SET GLOBAL slave_parallel_workers = 8; - 最后启动：
START SLAVE;
如果跳过 STOP SLAVE 直接设，MySQL 会接受命令但不重置 worker 线程池，旧线程继续跑，新配置下次重启才生效。错误日志里会出现类似 Changing slave_parallel_workers while slave is running is not supported 的提示。
监控并行线程是否真在并行工作
光看线程数不够，得确认事务是不是真被分发到不同 worker：
- 查
SELECT * FROM performance_schema.replication_applier_status_by_worker;，看APPLIED_TRANSACTION列是否持续更新且不全一样 - 对比
SELECT COUNT(*) FROM performance_schema.replication_applier_status_by_worker WHERE LAST_APPLIED_TRANSACTION = '';，结果大于 0 说明有 worker 空闲，可能是因为主库提交太稀疏或事务依赖太强 - 留意
Seconds_Behind_Master是否稳定下降：如果忽高忽低，大概率是事务冲突导致 coordinator 频繁串行化回放
最容易被忽略的是 slave_preserve_commit_order 开关——它强制按 relay log 顺序提交，会显著削弱并行效果，但又是保证一致性所必需的。调优时得在“快”和“准”之间做权衡。
