必须同时设主库binlog_format=ROW、从库slave_parallel_type='LOGICAL_CLOCK'并停库重配三步操作，否则仅调slave_parallel_workers无效；因该参数仅为worker数量上限，非开关，且LOGICAL_CLOCK依赖主库ROW格式生成的last_committed等时钟信息。
直接说结论：只改 slave_parallel_workers 没用，必须同时满足主库 binlog_format=ROW、从库 slave_parallel_type='LOGICAL_CLOCK' 且停库重配三步操作，否则并行复制根本不会启动。
为什么设了 slave_parallel_workers 却没效果
这个参数不是“开关”，只是 worker 数量上限。常见错误现象是：SHOW SLAVE STATUS\G 中 Slave_SQL_Running_State 一直卡在 “Reading event from the relay log”，且查 performance_schema.replication_applier_status_by_worker 只返回一行（WORKER_ID = 1），说明仍为单线程。
-
slave_parallel_workers = 0：纯单线程 SQL 线程回放 -
slave_parallel_workers = 1：有 coordinator 架构，但只有一个 worker，实测比 = 0 还慢约 20% -
slave_parallel_workers > 1且slave_parallel_type != 'LOGICAL_CLOCK'：仍退化为单线程或仅按库分发（对单库无效）
slave_parallel_type='LOGICAL_CLOCK' 的硬性前提
该模式依赖主库 binlog 中的 last_committed 和 sequence_number 分组事务，缺一不可：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 主库必须执行
SET GLOBAL binlog_format = 'ROW'；MIXED或STATEMENT下逻辑时钟信息不完整，并行会静默失效 - 主库建议确认
binlog_order_commits = ON（默认开启，但需显式检查） - 主库若用了
NOW()、UUID()等非确定性函数，对应事务会被强制降级为单线程回放 - 从库若配置了
replicate-do-db或Replicate_Wild_Do_Table，slave_parallel_type=DATABASE会彻底失效，但LOGICAL_CLOCK不受影响
必须停库执行的三步顺序
截至 2026 年 6 月，slave_parallel_type 仍不支持热更新。跳过任一步，START SLAVE 会失败或静默降级：
- 主库先确认：
SET GLOBAL binlog_format = 'ROW'，并建议检查binlog_row_image = 'FULL' - 从库执行：
STOP SLAVE→SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK'→SET GLOBAL slave_parallel_workers = 4（建议从 4 起步，不超过 CPU 核心数） - 从库必须同步设置：
SET GLOBAL master_info_repository = 'TABLE'、SET GLOBAL relay_log_info_repository = 'TABLE'、SET GLOBAL relay_log_recovery = ON
大事务仍是并行复制的“拦路虎”
哪怕所有参数都配对，一个运行 30 分钟的 DELETE FROM huge_table WHERE ... 在从库仍只能由单个 worker 执行——整个并行队列会卡在这个事务上，后续所有事务排队等待。
另外，主库 binlog_group_commit_sync_delay 和 binlog_group_commit_sync_no_delay_count 参数会影响组提交密度，间接决定从库能并行多少事务；但这些优化只在大并发写入场景下才明显，小流量实例调了也看不出差别。
