在做用户运营分析时，一个高频需求是：根据用户的累计消费金额或积分，把用户标记到对应的会员等级上，然后统计各等级的人数、消费分布等指标。会员等级表往往是按金额区间定义的，例如0到999元是普通会员，1000到4999元是银卡会员，5000元以上是金卡会员。这时候如果直接写JOIN ... ON user.amount = level.min_amount，结果会一无所获，因为用户的金额几乎不可能正好等于区间的边界值。更麻烦的是，如果区间定义出现了重叠，一个用户可能同时匹配到两个等级，导致统计结果翻倍。这篇文章就来系统地解决这两个问题。
用BETWEEN实现非等值Join关联区间
等值Join只适用于两边字段完全相等的情况，而区间匹配本质上是非等值Join，需要用不等式条件来表达。SQL标准中的BETWEEN运算符正好可以表达闭区间判断，写法直观且可读性好。假设有两张表，一张是用户表user_stat，字段包含user_id和total_amount，另一张是会员等级表member_level，字段包含level_name、min_amount和max_amount，关联SQL可以这样写：
SELECT u.user_id,
u.total_amount,
l.level_name
FROM user_stat u
JOIN member_level l
ON u.total_amount BETWEEN l.min_amount AND l.max_amount;
这条语句的逻辑是：对每一个用户，遍历等级表，找出满足金额落在区间内的那一行。BETWEEN在语义上等价于total_amount >= l.min_amount AND total_amount <= l.max_amount，是一个左右都闭合的区间判断。需要注意的是，如果金额可能为0，区间下界要写0而不是1，否则0元的用户会匹配不到任何等级而被遗漏。
对于没有上界的最高等级，比如5000元以上是金卡，常见的做法有两种：一是给max_amount设置一个足够大的哨兵值，例如999999999；二是干脆把max_amount字段设为NULL，然后用l.max_amount IS NULL OR u.total_amount <= l.max_amount来判断。前者实现简单、SQL无需特殊处理，推荐在数仓建设中优先采用；后者语义更严谨，但会让优化器难以利用索引，需要根据实际情况权衡。
区间边界重叠导致数据膨胀的排查与修复
非等值Join最容易踩的坑就是一对多匹配。当等级表的区间定义存在重叠，例如银卡写的是1000到5000，金卡写的是5000到10000，那么金额正好等于5000的用户会同时命中两条记录，Join结果中就会出现重复行，统计人数时被算两次。这种问题往往在等级规则调整后突然爆发，而且只有边界值上的少数用户受影响，很容易被忽视。
排查方法是先对等级表自身做一次自检，找出重叠区间：
SELECT a.level_name AS level_a,
b.level_name AS level_b,
a.min_amount, a.max_amount,
b.min_amount, b.max_amount
FROM member_level a
JOIN member_level b
ON a.min_amount < b.max_amount
AND b.min_amount < a.max_amount
AND a.level_name != b.level_name;
如果这条查询返回了结果，说明区间定义存在交叠。修复的原则是统一采用左闭右开的区间约定，即每个等级的覆盖范围是[min_amount, max_amount)，下一位用户的起点正好是上一等级的终点。对应的Join条件改为：
SELECT u.user_id,
u.total_amount,
l.level_name
FROM user_stat u
JOIN member_level l
ON u.total_amount >= l.min_amount
AND u.total_amount < l.max_amount;
这样金额为5000的用户只会命中金卡一条记录，边界归属变得唯一且确定。左闭右开是数仓和数学领域的通用约定，建议在等级表设计文档中明确标注，并在ETL流程中加入上述自检SQL作为数据质量校验，防止后续维护时再次引入重叠。
大数据量下的性能优化技巧
非等值Join的性能瓶颈在于传统哈希Join和归并Join都依赖等值条件，遇到BETWEEN这类条件时，部分数据库会退化为嵌套循环加过滤的执行方式。如果用户表有千万行，等级表有十行，最坏情况要执行上亿次比较，查询会非常缓慢。优化的第一思路是引入一个等值条件，让优化器可以走哈希Join。比如给等级表增加一个关联维度字段，如会员体系ID或业务线ID，让Join条件变成ON u.biz_id = l.biz_id AND u.total_amount >= l.min_amount AND u.total_amount < l.max_amount，等值部分先做哈希分桶，不等式部分只在桶内做小规模过滤，性能可以提升一个数量级。
第二个思路是把区间Join转化为等值Join。如果等级的档位数量固定且不太多，例如按消费金额每1000元升一档，可以预先计算用户的档位编号：FLOOR(total_amount / 1000)，等级表也预先算好档位编号区间，这样就能用等值条件直接关联。对于区间不规则的场景，可以在用户表上落地一个level_id字段，由定时任务统一计算并回写，下游查询全部走等值Join，这也是数仓中处理缓慢变化维度的常见做法，查询性能最好，代价是引入了一定的数据加工延迟。
最后不要忽视索引的作用。在MySQL这类支持Index Nested Loop Join的数据库中，给等级表的min_amount和max_amount建联合索引，可以让外层每扫描一行用户记录时，内层通过索引快速定位候选区间，避免全表扫描等级表。不过要注意，BETWEEN两个字段同时出现在条件里时，只有第一个索引列能有效收敛范围，等级表本身通常很小，全表扫描反而可能更快，索引优化更适合区间表很大的场景，比如IP地址归属地查询、运费模板匹配等。动手优化之前，先用EXPLAIN观察执行计划，确认瓶颈到底是Join方式还是数据倾斜，再选择对应的手段，才能做到有的放矢。