MySQL 5.7默认slave_parallel_type=DATABASE仅跨库并行，单库无效；LOGICAL_CLOCK真并行需满足：ROW格式、binlog_order_commits=ON、高版本+WRITESET依赖追踪、slave_preserve_commit_order=ON。
slave_parallel_type=DATABASE 是默认陷阱
MySQL 5.7 默认的 slave_parallel_type=DATABASE 表面看启用了多线程，实则只对跨库写入生效。如果你的业务只用一个库（比如全在 app_db），哪怕设了 slave_parallel_workers=16，SQL 线程也永远只有一个在干活——其余 worker 全部挂起等待，SHOW PROCESSLIST 里全是 Waiting for an event from Coordinator。
这不是配置没生效，是设计如此：它根本不识别单库内事务间的并行可能性。
必须同时满足四个条件，LOGICAL_CLOCK 才真并行
slave_parallel_type=LOGICAL_CLOCK 不是开关一按就提速的魔法按钮。它依赖主库 binlog 中的 last_committed 和 sequence_number 字段做依赖判断，而这些字段只有在特定条件下才会被正确写入：
- 主库
binlog_format必须为ROW（MIXED有风险，STATEMENT直接失效） - 主库
binlog_order_commits=ON（默认开启，但别假设——SELECT @@binlog_order_commits;确认） - 主库 MySQL ≥ 5.7.22 或 ≥ 8.0.19 且启用了
binlog_transaction_dependency_tracking=WRITESET（否则last_committed退化为组提交批次号，粒度太粗） - 从库
slave_preserve_commit_order=ON（保证回放顺序不破坏一致性，尤其 OLTP 场景不能关）
为什么设了 LOGICAL_CLOCK 还卡在 Waiting for dependent transaction
看到 Slave_SQL_Running_State: Waiting for dependent transaction to commit，说明 write-set 机制已启用，但它正在“主动限速”——不是没并行，而是它发现上游事务改了太多行（比如单个事务更新 500 行用户积分），导致 write-set 哈希冲突高、依赖链长，系统宁可串行也不冒险乱序执行。
这时调大 slave_parallel_workers 没用。真正该做的是：
- 查主库慢日志，定位长期持有锁的大事务（
Rows_examined或Rows_affected异常高） - 拆分这类事务：把批量
UPDATE user SET score = score + ? WHERE id IN (…)改成每 50 行一批，加SLEEP(0.01)隔开 - 确认从库
innodb_flush_log_at_trx_commit=1（主库一致），避免刷盘阻塞掩盖真实瓶颈
Seconds_Behind_Master = 0 ≠ 数据已追平
这个值只是对比 relay log 最后一条事件的时间戳和从库系统时间，完全不反映当前正在执行的大事务进度。常见假象：
- 主库刚停写，从库 backlog 还剩 2GB relay log 没消化，
Seconds_Behind_Master却显示0 - 主库一个 30 秒的大事务刚提交，从库 SQL 线程还没开始执行它，
Seconds_Behind_Master先跳0，几秒后暴涨到30
要验证真实同步状态，必须用：SELECT MASTER_POS_WAIT('mysqld-bin.000005', 123456789, 0);（参数来自 SHOW MASTER STATUS）
返回 0 才代表 relay log 已完全消费完毕。监控脚本里别只取 Seconds_Behind_Master。
