inner join 无法处理区间匹配，必须改用 left join + 范围条件（如 >= and
为什么直接用 INNER JOIN 会漏掉或错配会员等级
当会员等级规则按消费金额分段定义（比如 0–999 元为青铜，1000–4999 为白银），而规则表存在范围重叠或边界未对齐时，INNER JOIN 基于等值匹配的机制根本无法处理区间判断。常见错误是写成 JOIN ON u.total_amount = r.min_amount，结果一条记录都关联不上。
真正需要的是「查找某个值落在哪一段区间内」，这本质上不是等值连接，而是范围查找 —— 必须改用条件式连接（ON 中带比较运算符）或子查询。
- 别用
=，改用BETWEEN或>= AND - 注意闭区间与半开区间的语义差异：比如
BETWEEN 0 AND 999包含两端，但若规则定义为「满1000才升白银」，则白银起点应是>= 1000，而非>= 999 - 多个规则段之间必须互斥且覆盖完整，否则会出现
NULL等级或重复匹配
用 LEFT JOIN + 范围条件实现单次精准匹配
这是最常用、可读性好、多数数据库（MySQL 5.7+、PostgreSQL、SQL Server）都支持的做法。关键在于把范围判断写进 ON 子句，并确保每条用户记录最多只命中一个等级段。
SELECT u.user_id, u.total_amount, r.level_name FROM users u LEFT JOIN membership_rules r ON u.total_amount >= r.min_amount AND u.total_amount <p>注意：<code>max_amount</code> 应设为「下一个等级的 <code>min_amount</code>」，即采用左闭右开区间 [<code>min_amount</code>, <code>max_amount</code>)，避免边界重叠。例如：</p>
- 青铜：
min_amount = 0,max_amount = 1000 - 白银：
min_amount = 1000,max_amount = 5000 - 黄金：
min_amount = 5000,max_amount = 9223372036854775807（用大整数代表“无上限”）
遇到多条匹配时，如何强制取最高/最低等级
如果规则表没做好互斥设计（比如两条规则都满足 total_amount >= 1000），JOIN 可能返回重复行。此时不能靠 DISTINCT 混过去 —— 它不保证取的是你想要的那个等级。
正确做法是用窗口函数排序后取首行，或用关联子查询限制唯一输出：
SELECT u.user_id, u.total_amount,
(SELECT level_name
FROM membership_rules r
WHERE u.total_amount >= r.min_amount
AND u.total_amount
-
priority是你手动定义的等级权重字段（黄金=3，白银=2，青铜=1），用于明确指定优先顺序 - MySQL 8.0+ 和 PostgreSQL 支持
LIMIT，SQL Server 用TOP 1 - 如果不用子查询，也可用
ROW_NUMBER() OVER (PARTITION BY u.user_id ORDER BY r.priority DESC)配合外层过滤
性能隐患：没有索引的范围 Join 很慢
当用户表和规则表都很大时，ON u.total_amount >= r.min_amount AND u.total_amount 会触发嵌套循环，执行计划里常看到 <code>Type: ALL 或 rows_examined 异常高。
优化核心就一条：给规则表的范围字段建复合索引，让数据库能快速定位候选段：
- MySQL / PostgreSQL：建
INDEX idx_range (min_amount, max_amount) - 但注意：仅靠这个索引仍无法高效执行「某值落在哪个区间」—— 更优解是把规则预处理成可查的有序结构，例如用
GENERATE_SERIES（PG）或临时映射表，或干脆在应用层做二分查找 - 另一个现实选择：如果规则段极少（CASE WHEN 替代
JOIN，完全规避连接开销
边界情况永远比想象中多：比如新用户金额为 NULL、规则表里有 min_amount > max_amount 的脏数据、浮点金额导致精度误差……这些都得在 JOIN 前加 WHERE u.total_amount IS NOT NULL 和数据清洗校验。
