Flink SQL的INNER JOIN默认爆内存，因其采用Regular Join，全量保存两侧流历史数据于State且无自动清理机制；即使低吞吐场景，24小时后State亦可达GB级，引发OOM、反压与GC问题。
流式 SQL 的 JOIN 不能直接套用传统数据库写法，必须显式控制时间范围和状态生命周期，否则作业很快 OOM 或结果漂移。
为什么 Flink SQL 的 INNER JOIN 默认会爆内存
标准写法如 SELECT * FROM orders INNER JOIN payments ON orders.order_id = payments.order_id 在 Flink 中触发的是 Regular Join，底层用 Hash Join 实现：两侧数据全量落盘到 State，且默认不清理。哪怕每秒只来 10 条订单和 5 条支付，运行 24 小时后 State 也可能超 GB 级别。
- 状态无 TTL 时，Flink 不知道哪些历史记录“永远不会再被匹配”，只能一直保留
- 即使业务上允许支付延迟最多 15 分钟，SQL 里没声明，Flink 就不敢删
- Checkpoint 大小飙升、反压加剧、TaskManager 频繁 GC 甚至 OOM 都是典型症状
INTERVAL JOIN 是双流关联最稳的起点
当业务能明确“匹配窗口”（比如支付必须在订单生成后 15 分钟内完成），就该强制使用 INTERVAL JOIN，它天然带状态裁剪能力。
- 语法必须包含时间条件，且只能用
BETWEEN ... AND ...形式，例如：p.payment_time BETWEEN o.order_time AND o.order_time + INTERVAL '15' MINUTE - 底层不存全量数据，只维护每个 key 在当前时间窗口内的记录，状态大小可控
- 要求两侧流都定义了
EVENT TIME和 watermark，否则报错Cannot perform interval join on streams without time attributes - 不支持
LEFT JOIN或RIGHT JOIN，只能是INNER JOIN或FULL OUTER JOIN
窗口 JOIN 要小心 TUMBLE 的语义陷阱
用 TUMBLE 做窗口 JOIN 看似直观，但容易误以为“只要在同一个 5 分钟窗口里就一定能关联上”——实际不是。
- 必须显式对齐窗口起止时间：
u.window_start = o.window_start AND u.window_end = o.window_end，漏掉任一条件会导致笛卡尔积 - 如果用户行为流和订单流的 event_time 字段精度不一致（比如一个毫秒级、一个秒级），
TUMBLE可能切出不同窗口，导致关联失败 - 窗口函数本身不解决乱序问题，仍需配置合理的 watermark 延迟，例如：
WATERMARK FOR event_time AS event_time - INTERVAL '5' SECONDS - 结果是“窗口快照”，不是持续更新；若某条订单在窗口关闭后才来，它不会补进已输出的窗口结果
维表 JOIN 别滥用 Temporal Table Function 的默认行为
关联 MySQL 或 HBase 维表时，TABLE(lookup_table) FOR SYSTEM_TIME AS OF o.proctime 这种写法看似自动处理时态，但隐含风险：
- 默认用
PROCTIME查维表，查到的是“查询那一刻”的最新值，无法回溯历史版本（比如用户地址变更前的订单，不该显示新地址） - 若维表更新频繁，而
lookup没配缓存（lookup.cache.max-rows、lookup.cache.ttl），每条流数据都打一次 DB，直接拖垮吞吐 - 更稳妥的做法是先将维表转为带
EVENT TIME的动态表，再用FOR SYSTEM_TIME AS OF o.event_time关联，确保时态一致性
真正难的不是写出能跑的 JOIN，而是判断哪条数据该被关联、哪条该被丢弃、哪条该等一等——这些决策必须从 SQL 里透出明确的时间语义和状态边界，而不是靠调大内存硬扛。
