说到SQL里的连接查询，等值匹配大家都很熟了，但一碰到“区间匹配”这种场景，很多人就容易掉坑里。比如，你想找出所有发生在某个促销活动时间段内的用户访问记录，或者匹配价格落在特定区间的商品。这时候，JOIN后面跟着的，可就不是简单的等号了。
不等值连接在什么场景下必须用
答案很明确：当你需要判断一条记录是否“落在”另一条记录的某个连续范围内时，非等值连接就派上用场了。典型的例子就是时间区间匹配。用户访问日志的时间戳，需要去关联当时所有生效的促销策略，而每条策略都有自己的开始和结束时间。这种关系，靠主键或者唯一键是没法直接关联的，核心逻辑变成了判断一个点是否在另一个区间内。
于是，你可能会写出这样的条件：ON log.time >= policy.start_time AND log.time <= policy.end_time。逻辑上完全正确，但性能上往往是个灾难。数据库优化器对这类非等值条件感到头疼，很难高效地利用索引，执行计划很容易退化成最笨的嵌套循环全表扫描，数据量一大，查询就慢得让人无法忍受。
为什么 NOT IN 或 != 不能替代不等值连接
这是个常见的误解区。有人觉得，用!=或者NOT IN也能排除一些结果，是不是能曲线救国？其实不然，这两者和区间匹配完全是两码事。
首先，!=在ON子句里，通常只表示“不等于”，它无法表达“在某个区间内”这种连续的范围概念。如果你写LEFT JOIN ... ON a.id != b.id，期望实现某种排除，结果很可能要么是得到一张巨大的笛卡尔积（因为每一行都可能和另一张表的许多行“不相等”），要么就是漏掉了真正需要匹配的行。
其次， 虽然非等值连接天生对优化器不友好，但并不意味着我们只能坐以待毙。合理的索引设计是提升性能的关键。这里有个要点：针对区间查询，有效的往往不是单列索引，而是复合索引。 假设我们有这样一个查询： 那么，在 为什么是这个顺序？因为数据库在执行 还有一种危险的写法，是把连接和过滤混在一起： 这本质上是一个隐式的 说到底，处理区间匹配从来不只是语法问题，它是一场关于数据分布、索引设计和数据库引擎能力的综合博弈。最后提一个容易被忽略却至关重要的点：务必确保业务逻辑的约束在数据库层面得到保障。比如，确保NOT IN (SELECT ...)是一个过滤操作，而非连接操作。它更严重的问题在于对NULL值的处理：只要子查询返回的结果集中包含任何一个NULL值，整个NOT IN条件的结果就会变成UNKNOWN
!=破坏连接语义，且优化器通常无法为其使用索引。NOT IN则存在NULL陷阱，且无法处理范围逻辑。用
BETWEEN + 复合索引提升区间匹配效率SELECT * FROM events e JOIN periods p ON e.ts BETWEEN p.start_ts AND p.end_ts;periods表上，最有帮助的索引应该是：CREATE INDEX idx_periods_range ON periods (start_ts, end_ts);BETWEEN判断时，会优先利用左边界（start_ts）进行快速筛选，定位那些“可能”包含目标时间点的区间起点，然后再在这些候选区间里，用右边界（end_ts）进行二次过滤。如果把顺序反过来，索引的效率就会大打折扣。
BETWEEN子句直接进行索引下推优化，有时需要将其显式改写为e.ts >= p.start_ts AND e.ts <= p.end_ts才能触发索引。gist这类专用的时空索引。避免
CROSS JOIN + WHERE 写法引发性能雪崩SELECT * FROM a, b WHERE a.val > b.low AND a.val < b.high;CROSS JOIN（笛卡尔积），然后再用WHERE条件进行过滤。当表比较小时，可能看不出问题。可一旦a表和b表的行数都上万，这个中间产生的笛卡尔积就会瞬间膨胀到亿级，直接耗尽内存，导致查询崩溃。
JOIN ... ON ...语法。这不仅是好习惯，更是给数据库优化器一个明确信号，让它有机会选择更优的连接算法，比如PostgreSQL就可能会尝试使用针对范围连接的Merge Join。LIMIT来挽救这种写法。优化器通常会先计算出完整的中间结果集，然后再进行截取，LIMIT并不能避免中间过程的性能灾难。ROW_NUMBER()）进行提前排序和剪枝，大幅减少需要参与连接的数据量。start_ts <= end_ts这个基本规则，通过检查约束（CHECK Constraint）或应用层逻辑被严格维护。一旦数据中混入了“开始时间晚于结束时间”的反向区间，那么所有基于BETWEEN的查询逻辑都会悄然失效，而这种错误往往极其隐蔽，难以排查。
