设slave_parallel_workers=8无效，因默认slave_parallel_type='DATABASE'仅支持跨库并行；单库场景需改用LOGICAL_CLOCK或WRITESET模式，并确保主库启用组提交或write-set依赖追踪。
开启 slave_parallel_workers 本身不会自动解决主从延迟持续增大问题——它只是“允许并行”，但是否真能并行、并行效率如何，完全取决于 slave_parallel_type 设置和主库的事务提交模式。
为什么设了 slave_parallel_workers=8 却没效果？
常见错误现象是：执行 SHOW SLAVE STATUS 发现 Seconds_Behind_Master 仍在缓慢上涨，SHOW PROCESSLIST 里只看到 1 个 SQL 线程在活跃，其余 worker 线程处于空闲或等待状态。
根本原因在于默认的 slave_parallel_type='DATABASE' —— 它要求“不同库的事务才能并行”。如果业务只写一个库（比如全走 app_db），哪怕开了 16 个 worker，也只会用到 1 个线程。
- 检查当前类型：
SHOW VARIABLES LIKE 'slave_parallel_type'; - 确认主库是否真有跨库写入：
SELECT DISTINCT table_schema FROM information_schema.tables WHERE table_schema NOT IN ('mysql','information_schema','performance_schema','sys'); - 单库场景下，
DATABASE模式等价于单线程，设再大的slave_parallel_workers都无意义
slave_parallel_type=LOGICAL_CLOCK 的真实前提
这个值能让单库内事务也并行，但有个硬性前提：主库必须启用组提交（group commit），且事务需满足“逻辑时钟可并行”条件——即它们在 binlog 中属于同一 last_committed 组。
如果主库 binlog_group_commit_sync_delay 过小（如 0）、或写入压力低导致事务零散提交，last_committed 值就很难重复，从库仍无法分组并行。
- 查主库组提交效果：
SHOW GLOBAL STATUS LIKE 'Binlog_group_commit_%';关注Binlog_group_commit_trigger_count是否显著大于 0 - 从库开启前必须
STOP SLAVE，否则动态设置slave_parallel_type会失败 -
LOGICAL_CLOCK模式下，slave_parallel_workers建议设为 CPU 核数的 2–4 倍，但超过 16 后收益递减明显
MySQL 8.0+ 用户容易忽略的 WRITESET 陷阱
8.0 默认启用 WRITESET 并行（依赖 binlog_transaction_dependency_tracking=WRITESET），理论上比 LOGICAL_CLOCK 更细粒度。但实际中常因两个配置缺失而退化：
- 主库未显式开启：
SET PERSIST binlog_transaction_dependency_tracking = 'WRITESET'; - 从库
slave_parallel_type仍为LOGICAL_CLOCK或未重启生效，导致 WRITESET 信息被忽略 - 主库表缺少主键或唯一键时，WRITESET 无法精确追踪行级依赖，自动降级为
COMMIT_ORDER，并行度大幅下降
真正起效的关键不在数字调大，而在确认“主库产生的 binlog 是否携带足够并行信号” + “从库是否按预期解析了这些信号”。slave_parallel_workers 只是线程池大小，不是魔法开关。
