JOIN日期范围匹配需避免笛卡尔积，应使用BETWEEN或等值条件并确保索引；先过滤再JOIN、合并重叠区间；LEFT JOIN的时间条件必须放在ON而非WHERE中，否则会退化为INNER JOIN。
JOIN时日期范围匹配要避免笛卡尔积
直接用 BETWEEN 或 a.start_date = b.date 做 JOIN，若任一侧存在大量重叠区间或空值，极易触发全量配对——比如 1000 条时间区间 × 10000 条日志记录，生成千万级中间行。这不是慢的问题，是结果错得离谱。
实操建议：
- 确保被 JOIN 的日期字段都有索引，尤其是范围表的
start_date和end_date - 先过滤再 JOIN：用
WHERE b.date >= '2024-01-01'限定右表时间边界，别把十年日志全拖进来 - 对区间表做预处理：合并重叠区间（如用窗口函数识别连续段），减少无效匹配路径
LEFT JOIN + 时间范围条件必须写在ON里，不能放WHERE
这是最常踩的坑：把日期范围判断写在 WHERE 子句，会导致 LEFT JOIN 退化成 INNER JOIN。例如想查每天销售数据，并关联当天所属促销活动，但某天没活动——本该保留销售记录、活动字段为 NULL，结果这条记录直接消失。
正确写法示例：
SELECT s.date, s.amount, p.promo_name FROM sales s LEFT JOIN promotions p ON s.date >= p.start_date AND s.date <= p.end_date;
错误写法（会丢数据）：
SELECT s.date, s.amount, p.promo_name FROM sales s LEFT JOIN promotions p ON s.date = p.date -- 假设这里只靠单日等值 WHERE s.date BETWEEN p.start_date AND p.end_date; -- 这里p字段为NULL时整行被过滤
PostgreSQL 中可用 OVERLAPS 简化区间判断
PostgreSQL 提供原生语法 (a.start_date, a.end_date) OVERLAPS (b.start_date, b.end_date)，自动处理端点闭开、NULL 安全和顺序无关问题。MySQL 和 SQL Server 没这功能，得手写逻辑。
注意点：
-
OVERLAPS认为[2024-01-01, 2024-01-01]和[2024-01-01, 2024-01-01]是重叠的（左闭右闭），符合多数业务场景 - 如果区间字段含 NULL，
OVERLAPS返回 NULL，需配合IS NOT NULL显式过滤 - SQL Server 用户可用
DATEADD(day, -1, end_date)统一转为左闭右开，再手写a_start
大时间跨度下用分区裁剪或物化路径提升性能
当范围表横跨数年、且查询只关注最近 30 天时，即使有索引，优化器也可能放弃使用。这时候得帮它一把。
可行方案：
- 按年/月对范围表做分区（如 PostgreSQL 的
PARTITION BY RANGE (start_date)），让查询自动跳过无关分区 - 给范围表加冗余字段
year_month CHAR(7)，并在 JOIN 条件中加入AND p.year_month = TO_CHAR(s.date, 'YYYY-MM')，引导索引走查 - 对高频查询的时间维度（如“每日归属哪个费率区间”），预计算并存入宽表，避免每次 JOIN 实时计算
日期范围 JOIN 不是语法问题，是数据分布、索引策略和执行计划的组合题。没建对索引，写再准的 ON 条件也白搭。
