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

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

同一段 SQL，离线任务算出的订单金额是 1000 万，实时看板是 998 万。很多团队会先对 SQL 文本，确认 join、filter、group by 看起来一致，然后把差异归因成“实时有延迟”。

SQL 一致只是最表面的一层。批处理读的是一个有界快照，流处理消费的是持续变化的 changelog；两边如果没有停在同一个数据边界上，就连应该相等的时刻都没有定义。再叠加事件时间、watermark、迟到数据、UPDATE/DELETE 和 sink 主键，数值不同反而是正常结果。

Flink 1.13.1 的动态表文档有一句很重要的话：连续查询在任意时刻的结果，语义上等价于在输入表快照上执行同一批查询。这个“输入表快照”就是批流对账需要构造的参照物，而不是墙上时间写着几点。