mysql 5.7并行复制延迟主因是未真正并行：需设slave_parallel_type=logical_clock、主库启用writeset（binlog_format=row且≥5.7.22）、避免长事务，并合理配置worker数。
MySQL 5.7 的并行复制在小压力下仍有延迟，不是因为并发不够，而是因为「根本没真正并行起来」——多数情况是配置未生效、事务粒度太粗，或底层依赖缺失，导致 worker 线程压根没被调度。
slave_parallel_type 还是 DATABASE 就等于没开
这是最常见也最容易被忽略的问题。默认值就是 DATABASE，而你的业务只写一个库（比如 app_db），那哪怕 slave_parallel_workers=16，也只会用 1 个 worker 处理全部事务。
- 必须显式执行：
STOP SLAVE; SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK'; START SLAVE; - 确认生效：
SHOW VARIABLES LIKE 'slave_parallel_type';返回值必须是LOGICAL_CLOCK，不是DATABASE - 检查线程：
SHOW PROCESSLIST;应看到多个状态为Waiting for an event from Coordinator的Worker线程，而不是只有SQL Thread
主库没开 WRITESET，从库只能退化成 COMMIT_ORDER
LOGICAL_CLOCK 模式下，并行效果严重依赖主库能否提供精确的事务依赖关系。若主库 binlog_transaction_dependency_tracking 仍是默认的 COMMIT_ORDER（MySQL 5.7 默认），那从库只能按提交时间粗略分组，小事务之间依然容易串行。
一款AI工具，主要用于使用 OpenAI Codex CLI 处理编码任务。触发词：codex、code review、fix CI、refactor code、implement feature、coding agent、gpt-5-codex。Clawdbot 可将编码工作委托给 Codex CLI 作为子代理或直接工具，适合需要提升相关任务效率的用户。
- 主库需设：
SET GLOBAL binlog_transaction_dependency_tracking = 'WRITESET'; - 该参数要求
binlog_format = ROW，否则无效；STATEMENT或MIXED下WRITESET直接不工作 - MySQL 5.7 支持
WRITESET，但需确保版本 ≥ 5.7.22（早期 5.7.x 存在 bug）
长事务或单事务更新太多行，直接卡死整个队列
并行复制不是“拆事务”，而是按事务组（last_committed 相同）分发。一个运行 5 秒的大事务，会阻塞所有后续事务的 last_committed 推进，导致后续事务无法并行，哪怕只有 10 QPS 也会积压。
- 查主库长事务：
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(timediff(now(), trx_started)) > 5; - 避免批量 DELETE/UPDATE 不加 LIMIT；业务侧应主动分页，例如每次处理
WHERE id BETWEEN ? AND ? - 从库上
Seconds_Behind_Master不涨，但Exec_Master_Log_Pos几乎不动，大概率就是这个原因
Coordinator 分发不过来，worker 全在空等
当事务本身很轻（比如大量单行 INSERT），但 slave_parallel_workers 设得过高（如 16），Coordinator 线程要频繁做冲突检测、分发、等待协调，反而成了瓶颈。你看到的现象是：多个 Worker 线程状态是 Waiting for an event from Coordinator，但实际没活干。
- 建议从
4起步，观察performance_schema.replication_applier_status_by_worker中各 worker 的APPLIED_TRANSACTION推进是否均衡 - 若只有 1–2 个 worker 持续活跃，其余长期空闲，说明不是并发不足，而是事务可并行度低或 Coordinator 压力大
- 跨机房同步时，网络 RTT 高（如北京⇄广州 ≈ 30ms），Coordinator 每次 fetch event 都要等网络往返，worker 再多也白搭
真正卡住延迟的，往往不是 worker 数量，而是事务之间的隐式依赖、主库组提交能力、以及 Coordinator 和磁盘 I/O 的响应节奏。调参前先看 SHOW PROCESSLIST 和 performance_schema 表，比盲目改 slave_parallel_workers 有用得多。
