ON中使用BETWEEN或范围比较易致笛卡尔积膨胀，主因是优化器难估选择率、区间重叠导致匹配行数激增、隐式类型转换使索引失效，且BETWEEN的闭区间特性在时间字段含毫秒时易漏数据；LATERAL+LIMIT 1可精准实现事件与唯一配置段的一对一匹配。
为什么 ON 里写 BETWEEN 或比较运算符容易出错？
SQL 的非等值 JOIN（比如用时间范围匹配）常被写成 ON a.start_time = b.event_time，但实际执行时可能意外产生笛卡尔积式膨胀。根本原因是：优化器难以准确估算范围条件的选择率，尤其当时间区间重叠严重、数据分布不均时，JOIN 前置过滤失效，中间结果暴增。PostgreSQL 可能走 Nested Loop，MySQL 8.0+ 虽支持 Range Join 优化，但仅限于特定模式（如单边范围 + 索引覆盖），多数情况仍退化为全量扫描。
- 时间字段没索引或类型不一致（如
event_time是TIMESTAMP，而start_time是DATE）会导致隐式转换，索引完全失效 - 区间表（如时段配置表）若存在大量重叠（例如同一资源被反复划段），
JOIN后每条记录可能匹配多行，业务语义上却只该取“最精确”或“最新生效”的那一段 - 使用
BETWEEN易忽略边界包含逻辑，BETWEEN '2024-01-01' AND '2024-01-01'实际等价于= '2024-01-01'，但若字段含毫秒，可能漏掉'2024-01-01 00:00:00.123'
用 LATERAL + LIMIT 1 控制“一对一”匹配
当目标是为每个事件找“当时生效的唯一配置段”（例如查某次订单归属哪个促销活动期），LATERAL 是更可控的方式——它把右侧子查询变成左侧行级函数调用，天然避免爆炸式中间结果。
SELECT e.id, e.event_time, cfg.name
FROM events e
LEFT JOIN LATERAL (
SELECT name
FROM configs
WHERE e.event_time >= start_time
AND e.event_time
- 必须给
configs表在(start_time, end_time)上建复合索引，且把排序字段（如priority）也加入索引尾部，否则LIMIT 1无法快速终止 -
ORDER BY顺序决定“优雅”的含义：按优先级降序 → 按生效时间倒序，确保取到业务上最应匹配的那一条 - 若不用
LATERAL（如旧版 MySQL），可改用相关子查询 +ROW_NUMBER()窗口函数，但需注意窗口函数不能直接用于ON条件，得先套一层 CTE
PostgreSQL 的 tsrange + && 运算符真香但有陷阱
PostgreSQL 提供时间范围类型 tsrange 和重叠判断运算符 &&，写法简洁：ON tsrange(a.start_time, a.end_time) && tsrange(b.event_time, b.event_time)。但它默认使用「包含右端点」语义（[)），而日常业务中时间段多为左闭右开（如 [2024-01-01, 2024-01-02)），若建表时没显式指定 tsrange(start, "end", '[]') 或 '[)'，就可能漏匹配边界值。
-
tsrange索引（GiST）对重叠查询效率极高，但无法加速@>（包含）或（被包含）这类操作，除非额外建表达式索引 - 如果事件时间是单个时刻（
TIMESTAMP），别强行转tsrange；直接用event_time 更清晰，且能命中 GiST 索引 - MySQL / SQL Server 用户别盯着这个看——它们没有原生范围类型，硬模拟只会让查询更难维护
别忘了物化中间状态：预计算区间关系
当时间范围表变更极少（如年度日历、固定班次表），而事件表极大（日增千万级），每次实时 JOIN 都是性能灾难。此时应主动物化匹配关系：
- 建一张
event_to_config_map表，用定时任务（如每日凌晨）批量跑INSERT ... SELECT，把当天所有事件和有效配置段的关系固化下来 - 关键是加
WHERE event_time >= CURRENT_DATE - INTERVAL '1 day'这类明确分区谓词，避免扫全表 - 若业务允许轻微延迟（如 T+1 报表），这种方式比任何“优雅写法”都实在；实时性要求高的场景，才值得投入
LATERAL或tsrange优化
时间范围 JOIN 的“优雅”，本质是权衡：要不要为单次查询牺牲可维护性？是否接受定时任务带来的延迟？有没有人会去改那个看似静态的配置表？这些比语法本身更影响落地效果。
