BETWEEN在区间JOIN中易失效，因其无法被优化器识别为标准范围扫描条件，导致漏记录或全表扫描；应拆分为o.event_time >= p.valid_from AND o.event_time < p.valid_to。
为什么BETWEEN在区间JOIN里容易失效
BETWEEN不是语法错误，但会让优化器无法识别为标准范围扫描条件，尤其在字段含时区、精度不一致或隐式转换时，可能漏掉边界相接记录，甚至退化成全表扫描。它也不支持索引下推——数据库没法用它做Sargable谓词。
正确做法是拆成两个独立条件：o.event_time >= p.valid_from 和 o.event_time ，且必须同时出现在<code>ON子句中。这样既明确表达交集逻辑，又能让优化器走Range扫描。
- 务必加
AND p.valid_from IS NOT NULL AND p.valid_until IS NOT NULL，避免NULL干扰索引选择 - 如果右表时间字段允许NULL，优先在写入层清洗，而不是查询时用
COALESCE包裹 - 闭区间（DATETIME和
TIMESTAMP的微秒截断差异
分区裁剪没触发？先检查WHERE和JOIN是否都约束了时间
建了PARTITION BY RANGE (event_time)和INDEX (event_time)，但EXPLAIN仍显示type: ALL，大概率是分区裁剪根本没激活——优化器需要从WHERE中推导出可排除的分区边界，而JOIN条件要让右表能走单一分区内的索引扫描。
-
WHERE必须带硬时间约束，例如WHERE o.event_time >= '2026-05-01' AND o.event_time （开区间更安全） -
JOIN条件里必须包含分区键的等值或区间匹配，比如o.event_time BETWEEN p.valid_from AND p.valid_until，且p.valid_from要是分区键 - 左右表时间字段类型必须严格一致：
DATETIME对DATETIME，不能一边是TIMESTAMP一边是DATETIME - 禁止在分区键上用函数：
DATE(o.event_time)或o.event_time + INTERVAL 1 HOUR会直接禁用裁剪
LEFT JOIN + 区间匹配为何越查越慢
LEFT JOIN配区间条件（如o.time BETWEEN p.from AND p.to）极易引发笛卡尔爆炸：左表每行可能匹配右表多条区间记录，结果集规模变成O(n×m)，内存暴涨、执行卡死。
- 不要靠
LIMIT硬截断——这治标不治本，中间结果仍被全算出来 - 改用窗口函数提前剪枝：
ROW_NUMBER() OVER (PARTITION BY o.id ORDER BY p.valid_from DESC)，外层取rn = 1 - PostgreSQL可用
LATERAL+LIMIT 1，显式表达“为每行找一条最优匹配”，优化器更容易选索引扫描 - MySQL 8.0+必须确保
valid_from有索引，且ORDER BY字段是该索引前缀，否则排序代价远超JOIN本身
索引顺序怎么排才让区间JOIN真正走索引
索引不是建了就生效，顺序错了等于白建。对区间JOIN，关键不是“有没有索引”，而是“索引能不能支撑Range扫描+后续过滤”。
- 右表的联合索引必须是
(valid_from, valid_until)，不能反过来——只有前导列valid_from能用于范围定位 - 如果查询还带其他过滤条件（如
WHERE p.status = 'active'），索引应扩展为(status, valid_from, valid_until)，等值条件放最左 - 避免在
ON里对字段做任何运算：DATE(p.valid_from)、p.valid_from::date、COALESCE(p.valid_from, ...)都会让索引失效 - 用
EXPLAIN确认key列是否命中预期索引，rows是否明显小于表总行数——如果还是ALL，说明条件没被索引覆盖
