DTS增量同步延迟突然飙升的主因是源库位点停滞或目标库写入阻塞；例如源库长时间无写入触发DTS-51009空拉取重试，或目标库CPU/IOPS打满导致INSERT堆积，需通过「延迟时间」与「延迟数据量」是否同步上涨来区分源/目标瓶颈。
为什么DTS增量同步延迟会突然飙升？
延迟不是线性增长的，往往在某个临界点后陡增，常见诱因是源库位点停滞或目标库写入阻塞。比如源库长时间无写入（只读库空闲超 30 分钟），DTS-51009: Fetch records 5 times but return empty 就会触发重试机制，表面看是“延迟”，实际是增量采集已断流；又或者目标库 CPU 持续 95%+、磁盘 IOPS 打满，INSERT 执行变慢，DTS 增量写入线程堆积，延迟时间就不断累加。
关键判断点：先看 DTS 控制台「延迟时间」和「延迟数据量」两个指标是否同步上涨。如果只有延迟时间涨、数据量几乎不动，大概率是源端无新 binlog；如果两者齐涨，重点查目标库负载和网络。
如何快速定位是源库、目标库还是网络瓶颈？
别猜，直接比对三组监控数据：
- 源库
SHOW GLOBAL STATUS LIKE 'Com_commit'和Seconds_Behind_Master（如为从库）——确认源端确实在持续写入且 binlog 生成正常 - 目标库
Threads_running、Innodb_row_lock_waits、磁盘iowait——若Threads_running > 50或锁等待突增，说明写入已排队 - DTS 任务页「网络延迟」指标（单位 ms）——跨地域任务若稳定在 50ms 以上，或抖动超过 ±30ms，TCP 重传概率大幅上升，
tcp_tw_reuse和缓冲区参数就得调
注意：阿里云 DTS 控制台的「RPS 实际值」如果长期卡在你设置的限速上限（比如设了 10000 RPS，监控图一直贴着 10000 走），说明 DTS 自身没瓶颈，问题一定在上下游。
调整 DTS 限速参数时最容易踩的三个坑
限速不是“越大越好”，盲目调高反而导致失败：
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 全量导出阶段调高并发线程数（如从默认 8 改为 32），可能让源库
CPU瞬间冲到 90%+，触发连接拒绝或慢查询堆积，SELECT /*!40001 SQL_NO_CACHE */ ...类语句执行变慢，整体耗时反而延长 - 降低 RPS 后未观察延迟数据量变化，只盯着「延迟时间」下降就以为好了——但 DTS 默认只缓存 7 天中间数据，若延迟数据量持续超 50GB，缓存溢出后任务会直接失败，报错
DTS-RETRY-ERR-0078 - 在结构导出或无主键表导出阶段重启任务，会强制从头开始——因为这些阶段不支持断点续传，而你可能根本没注意到当前处于哪个子阶段
实操建议：先用「暂停 → 观察 5 分钟 → 恢复」验证目标库能否扛住当前速率；再微调，每次只改一个参数（比如先调目标库 RPS，不动线程数），改完等 10 分钟看监控趋势再决定下一步。
MySQL 服务端参数不调，DTS 再怎么优化都白搭
很多团队只调 DTS，却忘了源/目标 MySQL 实例本身的配置才是底层支撑：
-
wait_timeout和interactive_timeout必须设为2147483（约 24.8 天），否则 DTS 的长连接会在空闲 8 小时后被 MySQL 主动 kill，报错Lost connection to MySQL server during query，任务反复重连重试，延迟雪球越滚越大 -
max_allowed_packet至少设为512M，尤其当源库有大字段（如 JSON、TEXT）或 DTS 启用了批量 INSERT 时，否则语句被静默截断，数据不一致还难排查 - 内网迁移务必关闭 SSL：
require_secure_transport=OFF，实测加密开销可增加 15%～20% 延迟，且对内网链路无安全增益
这些参数改的是 MySQL 服务端，不是客户端，也不需要重启 mysqld（部分可动态 SET，但持久化仍需改 my.cnf）。迁移完成后记得恢复合理值，避免长期安全隐患。
真正卡住的点，往往不在 DTS 界面那几个滑块上，而在源库 binlog 位点是否推进、目标库磁盘是否写满、TCP 缓冲区是否够大——这些地方一堵，DTS 再聪明也得干等。
