非等值JOIN通过BETWEEN或开闭区间条件实现左表字段落入右表区间，需避免重叠与缺口；若允许多匹配则用LATERAL或子查询取最高优先级；务必校验右表区间的自洽性。
用 BETWEEN 或开闭区间条件做非等值 JOIN 后再分组
非等值关联本质是让左表某字段落在右表定义的区间内，不是靠 = 匹配，而是靠 >= AND 或 <code>BETWEEN。常见于：用户年龄匹配年龄段、订单金额匹配佣金梯度、IP 地址匹配地理区域等。
直接写 JOIN ... ON a.val BETWEEN b.low AND b.high 是最直观方式，但要注意：BETWEEN 是闭区间（包含端点），若业务要求左闭右开（如 [10,20)），就得改用 a.val >= b.low AND a.val 。
- 右表（区间表）必须有明确的
low和high字段，且不能有重叠逻辑漏洞（否则一行可能命中多个区间，导致重复计数） - 若左表数据量大、右表区间多，性能容易变差——建议给右表的
low和high加复合索引（如(low, high)），部分数据库（如 PostgreSQL）还支持RANGE类型或gist索引优化 - MySQL 5.7+、PostgreSQL、SQL Server 都支持，但 SQLite 不支持在
ON子句中使用非等值条件进行JOIN（需改用子查询或CROSS JOIN + WHERE）
避免区间重叠导致的重复分组统计
如果区间表里存在 [0,10), [5,15), [10,20) 这类重叠定义，一条记录可能同时满足多个条件，JOIN 后会生成多行，GROUP BY 时就会被重复计入多个分组——这不是 bug，是逻辑错误。
解决办法不是靠 SQL 技巧“去重”，而是前置校验和设计约束：
- 入库前用触发器或应用层检查：新插入的区间不能与已有区间重叠（可用
NOT EXISTS (SELECT 1 FROM ranges r2 WHERE r1.low r2.low)） - 若必须容忍重叠（比如按优先级匹配），就别用
JOIN，改用LATERAL（PostgreSQL）或相关子查询，取最高优先级的那一个：(SELECT name FROM ranges r WHERE t.val >= r.low AND t.val - 临时补救：用
ROW_NUMBER() OVER (PARTITION BY t.id ORDER BY r.priority DESC)标记主区间，外层只取rn = 1
GROUP BY 必须包含区间标识字段，不能只靠原始值
很多人写完非等值 JOIN 后，直接 GROUP BY t.amount，结果发现每行都是独立分组——因为没把区间维度带进来。真正要统计的是“每个区间有多少条记录”，所以 GROUP BY 的对象必须是右表的分类字段（如 r.level_name、r.grade）或区间本身（如 r.low, r.high）。
示例（统计各佣金档位的订单数）：
SELECT r.commission_rate, COUNT(*) AS order_count FROM orders o JOIN commission_tiers r ON o.order_amount >= r.min_amount AND o.order_amount < r.max_amount GROUP BY r.commission_rate;
注意：r.commission_rate 是分组依据；如果 commission_tiers 表里没有命名字段，而只有 min_amount 和 max_amount，那就得 GROUP BY r.min_amount, r.max_amount，否则语义不清。
NULL 值和边界外数据容易被静默丢弃
非等值 JOIN 是内连接逻辑，默认不保留左表中找不到匹配区间的记录。比如所有 order_amount 都小于最小 min_amount，结果就是空集——而不是“0 条在最低档”。这点和等值 JOIN 一样，但更容易被忽略，因为看起来像“范围覆盖了全部”。
- 要用
LEFT JOIN并配合COALESCE(r.name, 'unmatched')显式捕获未匹配项 - 检查边界：确认区间是否真正连续（如
[0,100), [100,200), [200,∞)），特别注意NULL在比较中的行为（val >= NULL恒为UNKNOWN，即不成立） - 测试用例至少覆盖：刚好等于下界、刚好等于上界（看是否包含）、略小于下界、略大于上界、为
NULL
区间分组真正的复杂点不在语法，而在业务边界的定义是否自洽、可验证、可维护。写完 SQL 后，先查一遍右表区间是否有重叠、缺口、反向（low > high），比调半天 GROUP BY 更省时间。
