Interval JOIN需显式时间约束、双表Watermark及等值条件，Outer类型禁用处理时间；Watermark为硬性要求且须小于时间区间；Outer JOIN State易堆积，Full JOIN慎用；connector需手动配置rowtime与Watermark。
Interval JOIN 是流式双表关联最实用、最可控的方式，但它不是写个 JOIN 就能跑通的——必须显式声明时间约束、正确设置 Watermark，且不能用处理时间做 Outer 类型。
必须带等值条件 + 时间区间谓词
Interval JOIN 的 SQL 语法看着像普通 JOIN，但解析器会校验：至少一个 =（或 IN）用于 key 匹配，且必须有一个时间范围表达式，否则报错 ValidationException: Interval join requires at least one equi-join predicate and a time constraint。
合法的时间谓词包括：
l.ts BETWEEN r.ts - INTERVAL '5' SECOND AND r.ts + INTERVAL '10' SECONDl.ts >= r.ts AND l.ts-
l.ts = r.ts（等价于宽度为 0 的区间，极少用）
不合法的写法：l.ts > r.ts - INTERVAL '1' HOUR（单边条件）、l.ts != r.ts（非等值）、l.process_time > r.process_time（处理时间在 Outer Join 中不支持）。
Watermark 设置是硬门槛，不是可选项
Interval JOIN 依赖事件时间推进来清理 State。如果源表没定义 WATERMARK FOR xxx AS xxx - INTERVAL 'X' SECOND，作业启动时会直接失败，错误信息类似 Cannot generate watermarks for table 'xxx': no watermark definition found。
关键点：
- 两个流都必须有
WATERMARK定义，且类型一致（都用事件时间） - Watermark 延迟值（如
- INTERVAL '2' SECOND）要小于你时间区间的最小跨度，否则大量数据因迟到被丢弃 - 别用
CURRENT_TIMESTAMP直接生成时间字段再设 Watermark——它返回的是处理时间，需改用PROCTIME()或从消息中解析真实事件时间
INNER 和 OUTER 的 State 行为差异极大
Inner Interval JOIN 只输出匹配成功的记录，State 中不存“悬空”数据；而 Left/Right/Full 类型会把未匹配的左流或右流暂存进 State，等对方到来或超时才输出 +[L, null] 或 +[null, R]。
这意味着：
- Outer 类型必须配 Watermark 才能触发超时清理，否则 State 持续堆积
- Left JOIN 中，右流延迟超过区间上限后，左流数据才会被清出并输出 null 补位；但如果右流永远不来，这条左流就一直卡在 State 里——所以业务上要预估最大延迟，并据此设好 Watermark 延迟和区间宽度
- Full JOIN 的 State 开销是 Left + Right 的叠加，生产环境慎用，尤其当两路流基数差距大时
别忽略 connector 对时间字段的兼容性
Kafka、Pulsar、Datagen 这些 connector 默认不暴露时间字段，你得手动加 rowtime 列并设为事件时间属性。例如 Kafka JSON 源表：
CREATE TABLE click_log ( log_id BIGINT, click_params STRING, event_time BIGINT, -- 假设消息体里有毫秒时间戳 ts AS TO_TIMESTAMP_LTZ(event_time, 3), WATERMARK FOR ts AS ts - INTERVAL '5' SECOND ) WITH ( 'connector' = 'kafka', 'topic' = 'click-log', 'value.format' = 'json', 'scan.startup.mode' = 'latest-offset' );
常见坑：
- 用
TO_TIMESTAMP而不是TO_TIMESTAMP_LTZ→ 报错Invalid argument type，因为后者才支持事件时间语义 - JSON 字段名含大小写或下划线，但 Flink 默认转成小写 → 导致
event_time取不到值，ts为 NULL，Watermark 无法推进 - MySQL CDC 或 Debezium 源自带
processing_time，但 Interval JOIN 不认这个，必须显式提取op_ts或event_time字段
真正难的从来不是写对那条 SQL，而是让两路流的时间轴对齐、Watermark 稳定推进、State 不爆炸——这三件事没调顺之前，Interval JOIN 就只是个语法正确的空壳。
