DataX 任务跑慢了，很多人的第一反应是把 job.setting.speed.byte 往上调。这个动作有时有效，有时一点反应都没有，偶尔还会把目标库写得更慢。

问题出在我们很容易把它理解成一个总限速开关。DataX 启动前会用速度预算计算 Channel 数量，运行中再由每个 Channel 统计吞吐并决定要不要休眠。Reader 和 Writer 之间还有一个有界队列。任何一环跟不上，都会把前后两端拖住。

下面的代码基于 DataX 提交 30842ca，提交时间是 2020 年 11 月 9 日。这样可以避开后来版本的改动，也和这篇笔记的时间对得上。

DataX 一次同步任务可以压成一条主线：datax.py 组装 JVM 命令，Engine 读取任务 JSON，JobContainer 初始化并切分 Reader/Writer，调度器把 Task 分给若干 TaskGroupContainer，每个 Task 再用 Channel 连接 Reader 和 Writer。

这条链路里最容易混淆的是三个数量：Reader 切出了多少 Task、作业允许多少 Channel、每个 TaskGroup 能同时跑多少 Task。它们相关，但不是一个值。

这篇文章最初有 23 张调试截图，原 OSS 存储桶删除后无法恢复。2026 年整理旧文时，我没有继续保留空图片框，而是按 2020 年 10 月 13 日的 DataX 提交 3c03fedd 重新核对类和方法，并把真正需要看的关系重画成三张调用链图。原始发布时间不变，修订时间单独记录。