mysql 5.7并行复制性能提升不依赖库名差异，而取决于logical_clock模式下主库组提交产生的last_committed分组及writeset冲突检测；改库名无效，关键在主库启用writeset+row格式、从库配worker与table元数据存储。
MySQL 5.7 并行复制对不同库名的同步性能提升非常有限——默认启用 LOGICAL_CLOCK 后，库名差异本身不再构成并行调度依据，真正起作用的是事务间的逻辑时钟依赖关系，不是库名是否不同。
为什么改库名不能直接提升并行度
很多人误以为“把表拆到多个库就能触发并行”，这是沿袭 MySQL 5.6 的思维惯性。5.7 中：slave_parallel_type=DATABASE 才按库分发，但该模式已被弃用；默认且推荐的 LOGICAL_CLOCK 模式完全无视库名，只看主库写入时的 last_committed 和 sequence_number。即使所有表都在同一个库，只要主库有组提交，从库就能并行回放。
- 主库没开启组提交（
binlog_group_commit_sync_delay=0且binlog_group_commit_sync_no_delay_count过大），会导致事务几乎串行提交 → 从库看到的last_committed值高度重复 → 并行 worker 空转 - 主库用了
MIXED或STATEMENT格式，某些语句（如含UUID()、NOW()）会强制降级为单线程提交，破坏组提交连续性 - 从库上
slave_preserve_commit_order=ON（默认 OFF）会强制按主库顺序提交，抵消部分并行效果
真正影响多库场景下并行效率的关键参数
当业务确实存在多个库（比如 shop_db、user_db、log_db），且希望它们之间不互相阻塞，需确认以下三点：
-
slave_parallel_workers必须 > 0（建议设为 CPU 核心数的 2–4 倍，如 8 或 16），否则连 coordinator + worker 架构都不生效 -
master_info_repository和relay_log_info_repository必须设为TABLE，否则 crash safe 机制会退化，worker 线程在恢复时可能重复应用或跳过事务 - 主库必须开启 GTID（
gtid_mode=ON+enforce_gtid_consistency=ON），否则从库无法可靠识别事务边界，LOGICAL_CLOCK依赖的元数据可能缺失
WRITESET 模式下，库名更无关紧要
MySQL 5.7.22+ 支持 binlog_transaction_dependency_tracking=WRITESET，此时并行判断依据是事务修改的行集合（writeset）是否相交，和库名、表名、甚至是否跨库都无直接关系。但要注意：
- 主库必须设置
binlog_row_image=FULL（默认值），否则 writeset 计算不完整 - 唯一索引越多，writeset 越大，主库 binlog 体积增加，网络传输和从库解析开销上升
- 如果事务更新了同一行（比如两个库都更新
config_table中的同一条配置），即使库名不同，也会被串行化
真正卡住并行度的，从来不是库名是否不同，而是主库有没有产生足够多的、互不冲突的组提交事务，以及从库有没有配对的 worker 资源和可靠的元数据持久化机制。别花时间重命名库，去检查 SHOW MASTER STATUS 里的 Executed_Gtid_Set 是否连续、performance_schema.replication_applier_status_by_worker 里各 worker 是否长期 idle，那才是问题所在。
