Interval在Join中不直接参与关联逻辑，仅用于构造动态时间边界，真正关联依赖ON条件中的时间范围表达式。
什么是Interval函数在Join中的真实作用
INTERVAL 本身不是SQL标准函数，MySQL里它是DATE_SUB/DATE_ADD的快捷语法糖，PostgreSQL用INTERVAL '1 day'字面量，而ClickHouse、Trino等则支持更灵活的interval表达式。它不直接参与Join逻辑，而是帮你构造动态时间边界——真正做关联的还是ON里的条件表达式。
常见误解是以为写个INTERVAL就能自动“滑动窗口”，其实你得手动定义左表时间字段和右表时间范围的关系。
MySQL中用DATE_ADD + BETWEEN实现动态窗口Join
比如要查每个订单下单后7天内发生的物流轨迹事件：
SELECT o.order_id, l.event_time, l.status FROM orders o JOIN logistics l ON l.event_time BETWEEN o.order_time AND DATE_ADD(o.order_time, INTERVAL 7 DAY);
注意点：
-
DATE_ADD(o.order_time, INTERVAL 7 DAY)必须写在ON子句里，不能放到WHERE——否则会变成先全量Join再过滤，性能爆炸 - 如果
logistics.event_time没索引，这个Join大概率走不了range扫描，建议加复合索引：INDEX(event_time, order_id) - MySQL 5.7+ 支持函数索引（8.0更稳），但
DATE_ADD这类表达式无法被普通B+树索引直接利用，得靠event_time本身的有序性触发range access
PostgreSQL里用>= AND
BETWEEN包含上下界，在毫秒级时间场景下容易漏掉或重复一条记录。更稳妥写法是左闭右开：
SELECT u.user_id, a.action_time FROM users u JOIN actions a ON a.action_time >= u.signup_time AND a.action_time < u.signup_time + INTERVAL '30 days';
关键细节：
- PostgreSQL允许直接对
TIMESTAMP加INTERVAL字面量，不用套函数 - 如果
signup_time是TIMESTAMPTZ，action_time也必须同类型，否则隐式转换可能绕过索引 - 用
EXPLAIN ANALYZE确认是否走了Index Scan using actions_action_time_idx on actions，而不是Bitmap Heap Scan
ClickHouse中用arrayJoin + dateDiff做近似窗口Join（适合大宽表）
当右表是高频事件流（如每秒百条埋点），传统Join会因笛卡尔积崩掉。ClickHouse常用预计算窗口方式：
SELECT uid, event_time, arrayJoin(range(0, 7)) AS day_offset, toDate(event_time) + INTERVAL day_offset DAY AS window_date FROM events WHERE event_time >= '2024-01-01';
这不是真正Join，而是为后续与用户维表做JOIN ... ON toDate(u.join_date) = window_date铺路。适用前提：
- 窗口长度固定（如7天）、且可接受按天粒度对齐
- 左表是低频维度（用户/设备），右表是高频事实（点击/曝光）
- 必须确保
event_time有跳数索引（skipping index）或分区键含日期，否则arrayJoin会放大shuffle压力
真正难的不是写对INTERVAL，而是判断该不该用它——时间窗口Join最容易卡在数据倾斜（比如某个用户7天内产生10万条日志）和索引失效上。别急着堆语法，先看执行计划里有没有Rows Removed by Filter超过95%。
