非等值连接必须用于区间匹配场景，如时间落在某段区间内或价格在某个范围内，此时需用、between等非等号逻辑在on子句中定义连接条件，而非where子句。
不等值连接在什么场景下必须用
当你要找“某个时间落在某段区间内”的记录，或者“价格在某个范围中”的关联数据时，JOIN 条件里就绕不开 、<code>>、BETWEEN 这类非等号逻辑。比如：用户访问日志表要匹配上当天生效的促销策略表（策略有 start_time 和 end_time），没法靠主键或唯一键等值关联，只能靠区间重叠判断。
这时候硬写成 ON log.time >= policy.start_time AND log.time 是对的，但性能往往很差——因为数据库很难对这种非等值条件建有效索引，执行计划容易退化成嵌套循环（Nested Loop）全量比对。
为什么 NOT IN 或 != 不能替代不等值连接
NOT IN 是过滤子查询结果，不是连接逻辑；!= 在 ON 子句里通常只会筛掉相等的行，无法表达“落在区间内”这类连续范围关系。常见错误是误以为 LEFT JOIN ... ON a.id != b.id 能实现“排除自身”，结果要么笛卡尔爆炸，要么漏掉大量本该匹配的行。
-
!=在连接条件中几乎从不用于业务逻辑建模，它破坏连接语义，且优化器常拒绝使用索引 -
NOT IN (SELECT ...)无法处理NULL，一旦子查询返回任意NULL，整个条件判为UNKNOWN，结果集为空 - 真正需要的是“范围匹配”，不是“排除相等”，二者数学含义和执行路径完全不同
用 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);
原因：数据库可先用 start_ts 快速定位“可能包含该时间点”的起始段，再在这些段内用 end_ts 做二次筛选。若反过来建 (end_ts, start_ts)，效果会差很多——因为 BETWEEN 的左边界才是驱动过滤的关键。
- MySQL 8.0+ 和 PostgreSQL 支持函数索引，可考虑对
ts字段做归一化后再建索引（如按小时截断） - SQL Server 不支持
BETWEEN上的索引下推，需改写为e.ts >= p.start_ts AND e.ts 才能触发索引 - 如果区间大量重叠（如每秒都有新策略），索引收益下降，此时应预计算覆盖关系或改用专用时空索引（如 PostGIS 的
gist）
避免 CROSS JOIN + WHERE 写法引发性能雪崩
有人图省事把不等值连接写成：SELECT * FROM a, b WHERE a.val > b.low AND a.val
这本质是 CROSS JOIN 后过滤，在小表上看着快，一旦 a 和 b 都过万行，中间笛卡尔积就达亿级，内存爆满、查询卡死。
- 务必用显式
JOIN语法，让优化器有机会选择更优算法（如 PostgreSQL 的 Merge Join for ranges） - 加
LIMIT不能解决根本问题——优化器仍会先生成全量中间结果再截断 - 如果只关心“每个 a 匹配的第一个 b”，可用窗口函数提前剪枝：
ROW_NUMBER() OVER (PARTITION BY a.id ORDER BY b.end_ts - b.start_ts)
区间匹配从来不是语法问题，而是数据分布、索引设计和执行引擎能力的综合博弈。最容易被忽略的，是没检查 start_ts 这个业务约束是否在数据库层强制——一旦存在反向区间，所有 <code>BETWEEN 逻辑都会失效，且很难排查。
