非等值JOIN是使用BETWEEN、>、=、
什么是非等值JOIN，它和普通JOIN有什么区别
非等值JOIN不是用 = 连接两个表，而是用 BETWEEN、>= AND 、<code>、<code>> 等比较操作符来表达范围匹配关系。最典型场景就是“某条记录的时间戳落在某个时间区间内”——比如用户行为日志要关联到当天的营销活动周期。
普通等值JOIN（如 ON a.id = b.user_id）能走索引哈希或排序合并，效率高；而非等值条件通常无法直接利用B树索引的等值查找能力，容易触发全表扫描或嵌套循环，性能更敏感。
常见错误现象包括：
- 查询跑了几分钟没返回结果
- 执行计划里出现
Nested Loop且外层行数巨大 - 明明加了索引，但
EXPLAIN显示没被使用
如何正确写出时间区间匹配的JOIN语句
核心是把时间范围逻辑写进 ON 子句，而不是 WHERE。否则可能意外过滤掉本该保留的左表记录（尤其在 LEFT JOIN 中）。
假设你有两张表：events（含 event_time 时间戳）和 campaigns（含 start_time 和 end_time），想找出每个事件所属的活动：
SELECT e.id, e.event_time, c.name FROM events e LEFT JOIN campaigns c ON e.event_time >= c.start_time AND e.event_time <= c.end_time;
注意点：
-
LEFT JOIN保证所有events都保留，即使没匹配到活动 - 区间判断必须同时写两个边界，不能只写
e.event_time BETWEEN c.start_time AND c.end_time（虽然语义等价，但某些旧版MySQL对BETWEEN在JOIN中优化不佳） - 如果存在重叠区间，一条事件可能匹配多条活动记录——这是预期行为，不是bug
怎么让非等值JOIN不慢得没法用
关键不是“避免用”，而是“控制搜索空间”。主要手段有三类：
- 给时间字段建复合索引：比如在
campaigns(start_time, end_time)上建索引，能让数据库快速定位可能的起始区间（虽不能直接跳到精确区间，但比全扫好得多） - 先缩小右表数据量：用子查询或CTE预过滤明显无关的活动，例如
WHERE start_time - 拆分时间粒度：如果活动周期按天划分，可先用日期截断（
DATE(e.event_time) = DATE(c.start_time)）做等值预筛选，再在同一天内做精确时间比较
常见陷阱：
- 只给
start_time单字段建索引，end_time条件仍会全表扫 - 忘记处理时区，导致
event_time和start_time实际不在同一时区下比较 - 使用
STR_TO_DATE或函数包装字段（如DATE(event_time)）导致索引失效
PostgreSQL / MySQL / SQL Server 各自要注意什么
不同引擎对非等值JOIN的支持细节差异不小：
- PostgreSQL 支持
Range Types和gist索引，用tsrange+&&操作符能高效做区间重叠判断，比手写BETWEEN快一个数量级 - MySQL 8.0+ 的
EXPLAIN FORMAT=TREE能看清是否用了“range access on index”，但老版本只能靠EXPLAIN中的type字段看是不是range或index_merge - SQL Server 不支持在
ON中用复杂表达式下推索引，建议改用APPLY（尤其是CROSS APPLY带TOP 1找最近活动），有时比JOIN更可控
真正麻烦的是跨数据库移植：同一个 BETWEEN 写法，在MySQL里可能走索引，在SQL Server里却变成 Table Scan。上线前务必在目标环境跑 EXPLAIN 或执行计划。
时间区间JOIN的难点从来不在语法，而在于你是否清楚当前数据分布、索引状态、以及数据库到底打算怎么执行它。写完语句后不看执行计划，等于蒙眼开车。
