mysql主从延迟优化需启用logical_clock模式并正确配置：先查slave_parallel_type和slave_parallel_workers，若为database且单库写入则无效；须设为logical_clock、关闭binlog_order_commits、重启sql线程；worker数建议设为cpu核数1–2倍，避免超16；seconds_behind_master不准，应结合位置差、长事务及performance_schema监控真实延迟。
多线程同步（MTS）是解决 MySQL 从库延迟最直接有效的手段，核心是让多个 SQL 线程并行回放 relay log，打破单线程瓶颈。但开参数 ≠ 自动生效，关键在选对模式、配对参数、避开常见陷阱。
先确认是否真在用多线程
很多延迟问题其实压根没跑起来多线程：
- 查当前配置：
SELECT @@slave_parallel_type, @@slave_parallel_workers;—— 若slave_parallel_workers = 0或slave_parallel_type = DATABASE且业务只写一个库，那等于没开 - 看实际运行状态：
SELECT * FROM performance_schema.replication_applier_status_by_worker;—— WORKER_ID 大于 1 才算真正启用；全是 0 或只有 1 行，说明还是单线程干活 - 注意：改完参数必须重启 SQL 线程（
STOP SLAVE SQL_THREAD; START SLAVE SQL_THREAD;），光 SET GLOBAL 不触发重载
选对并行模式：LOGICAL_CLOCK 是主力
DATABASE 模式只按库分组，单库写入场景下完全无效。LOGICAL_CLOCK 模式基于主库的组提交信息（last_committed），只要主库开启了 binlog 组提交，就能把逻辑上无冲突的事务分发到不同 worker：
- 主库确保：
binlog_order_commits = OFF（默认开启，需关掉，否则人为串行化提交） - 从库设置：
SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK'; - 配套必须打开：
SET GLOBAL slave_preserve_commit_order = ON;—— 否则并行执行会打乱事务顺序，导致主从数据逻辑不一致 - binlog 格式必须为
ROW或MIXED；STATEMENT 下 LOGICAL_CLOCK 不工作
调好 worker 数量：不是越多越好
worker 数要匹配硬件能力，盲目设高反而拖慢：
- 推荐值：物理 CPU 核数的 1–2 倍（如 8 核服务器设 8 或 16）
- 上限建议不超 16：超过后线程调度、relay log 文件读取、
slave_worker_info表锁竞争等开销会明显上升 - 观察效果：设完后盯
SHOW PROCESSLIST中多个Worker线程的State，若长期卡在Waiting for an event from Coordinator，说明任务分发不足或有阻塞点
别被 Seconds_Behind_Master 蒙蔽
这个值在 GTID 模式下可能失真，且无法反映正在执行的大事务阻塞：
- 更准的方法是比对位置：
SHOW SLAVE STATUS\G中Read_Master_Log_Pos和Exec_Master_Log_Pos的差值，再结合Relay_Log_Pos判断真实追赶进度 - 查长事务：
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), TRX_STARTED)) > 60;—— 大事务（如 ALTER、全表 UPDATE）会独占一个 worker，后续事务排队，MTS 效果归零 - 如果发现 SQL 线程长期停在
Updating或Waiting for table metadata lock，说明是语句执行慢或锁等待，得优化 SQL 或拆分事务，MTS 解决不了这类底层瓶颈
