MySQL多线程复制默认模式slave_parallel_type=DATABASE仅支持跨库并行，单库场景下无论slave_parallel_workers设多大均退化为单线程回放；真正实现事务级并行需切换为LOGICAL_CLOCK模式并确保主库binlog_format=ROW及binlog_order_commits=ON。
slave_parallel_type = DATABASE 是 MySQL 5.6 及早期 5.7 版本中多线程复制的默认模式，它直接决定了并行能力的天花板。
MySQL 5.6 的多线程复制只支持按库（database）分发事务，slave_parallel_workers 再大也救不了单库场景——只要所有写操作集中在同一个库，所有事务就只能排队交给同一个 worker 线程执行，实际仍是单线程回放。
这个限制在真实业务中几乎无法绕过：绝大多数应用使用单库多表结构，比如 shop 库下有 orders、users、products 等几十张表。即使主库并发很高，从库仍卡在 Reading event from the relay log 状态，Seconds_Behind_Master 持续上涨。
更隐蔽的问题是跨库事务处理：当一个事务同时修改 db1.t1 和 db2.t2，coordinator 必须等两个库各自的 worker 都空闲才能分配，反而引入额外等待；而 DDL 或涉及 >254 个库的操作会强制退化为单线程执行，导致延迟尖峰。
真正让多线程复制“能用”的转折点是 MySQL 5.7 引入 LOGICAL_CLOCK 模式，它不再依赖库名隔离，而是靠主库 binlog 中的 last_committed 时间戳分组事务。但前提是主库必须开启 binlog_format = ROW 且 binlog_order_commits = ON，否则从库根本解析不出逻辑时钟信息。
容易被忽略的关键点：很多人在 5.7 上把 slave_parallel_workers 设成 8 就以为开启了并行，却没改 slave_parallel_type，结果 SHOW VARIABLES 里还是 DATABASE —— 这种配置下，哪怕你有 100 个库，只要其中 99 个库零写入，剩下 1 个库扛全部流量，照样单线程。
