Flink SQL 作业变慢后，最常见的动作是加并行度、调 managed memory、扩大 checkpoint timeout。这样有时能缓解问题，但也容易把一份错误的物理计划跑得更贵。

我接手一条 SQL 时，第一份材料不是 Web UI 截图，而是当时 Catalog、配置和 SQL 共同生成的 EXPLAIN。SQL 只是意图，真正消耗网络、状态和 CPU 的是优化后的物理节点。Join 选了广播还是 shuffle、聚合有没有两阶段、哪条边产生 Exchange、输出是 append 还是 retract，这些决定比一个笼统的“数据量大”更接近根因。

Flink 作业平时运行正常，一到流量高峰，checkpoint duration 突然从几十秒拉长到超时。第一反应通常是 RocksDB 或 HDFS 写得慢，于是继续调 checkpoint timeout。超时时间变长以后，失败次数可能少了，恢复点却越来越旧，背压也没有消失。

Checkpoint 的端到端时间不只是“状态写入存储”的时间。barrier 从 source 往下游传递，要先穿过已有的数据和网络缓冲；多输入算子还要等各个 channel 的同一轮 barrier 到齐。上游或下游已经背压时，barrier 本身就可能走不动，状态后端甚至还没开始做主要工作。

我排查这类问题时，会先把一次 checkpoint 拆成 start delay、alignment、同步快照和异步落盘四段。只有知道时间花在哪一段，参数调整才有意义。