seconds_behind_master不可信，真实延迟需看read_master_log_pos与exec_master_log_pos差值，并结合slave_io_running、slave_sql_running状态及pt-heartbeat实测验证。
Seconds_Behind_Master 一直不降？先别急着调参
这个值只是个估算，不是真实延迟。它依赖主库写入 binlog 时打的时间戳，如果从库系统时间比主库快、或者主库时钟漂移，Seconds_Behind_Master 可能显示为 NULL 或负数，完全不可信。
真正要盯的是两个位点差：
-
Read_Master_Log_Pos和Exec_Master_Log_Pos的差值——反映 relay log 拉取和执行之间的积压量 -
Master_Log_File和Relay_Master_Log_File是否一致——不一致说明 IO 线程或 SQL 线程卡在中间环节
用 SHOW SLAVE STATUS\G 查完后，再结合 SHOW PROCESSLIST 看 Slave_SQL_Running_State：如果是 Waiting for dependent transaction to commit，大概率是并行复制被锁住；如果是 Reading event from the relay log 却不动，得查磁盘 IO 或 relay log 写入是否卡住。
slave_parallel_workers 设多少才有效？
设成 8 或 16 不等于真有 8 个线程在干活。MySQL 5.7 的 slave_parallel_type=DATABASE 要求事务必须跨库才并行，单库写入再多线程也白搭。
实操建议：
- 确认主库是否真的多库写入：
SELECT db, COUNT(*) FROM information_schema.processlist GROUP BY db; - 升级到 MySQL 8.0+ 后，改用
slave_parallel_type=LOGICAL_CLOCK+binlog_transaction_dependency_tracking=WRITESET，才能按事务粒度并行 -
slave_parallel_workers值建议设为 CPU 核数的 2–3 倍，但必须配合STOP SLAVE; START SLAVE;才生效，动态 SET 后不重启线程不会加载新配置
大事务正在拖垮从库？立刻拆分，别等
一个 DELETE FROM orders WHERE created_at 跑 20 分钟，从库 SQL 线程就卡死 20 分钟，后续所有事务全排队。这不是“慢”，是“堵”。
现场止损办法：
- 在从库执行
KILL掉正在执行的大事务线程（注意：只 kill 从库的 SQL 线程 ID，不是主库的） - 主库侧改用分批删：
DELETE FROM orders WHERE created_at ，每次 sleep 100ms 再执行下一批 - 长期预防：业务层加校验，禁止无
LIMIT的 DML；DBA 层用 pt-kill 监控并自动 kill 运行超 60s 的事务
硬件和网络没配平，调参全是空转
见过太多团队把 slave_parallel_workers 调到 32，结果从库 CPU 才 4 核、磁盘还是 SATA SSD——线程越多，上下文切换越频繁，延迟反而更高。
必须检查的硬指标：
- 从库
innodb_buffer_pool_size至少为主库的 1.2 倍，否则大量页要刷盘回放 - 主从间 ping 延迟必须 ≤ 0.5ms（同机房），跨可用区延迟 > 2ms 就该重构拓扑
- 从库磁盘 IO util 持续 > 80%？换 NVMe；
iostat -x 1看%util和await，后者 > 20ms 就算瓶颈
最常被忽略的一点：从库 sync_binlog 和 innodb_flush_log_at_trx_commit 如果设为 1，会强制刷盘，极大拖慢回放速度——生产环境从库可设为 0，只要不丢数据就行。
