应使用 >= and = and =”和“>= and = r.min_price and p.price”等写法存在语法错误或逻辑冗余。
用BETWEEN还是>= AND
直接用 BETWEEN 在 JOIN 条件里是错的——它不支持跨表字段动态比较。比如写 ON p.price BETWEEN r.min_price AND r.max_price 看似合理，但多数数据库（PostgreSQL、SQL Server）会报错或产生意外结果，因为 BETWEEN 要求左右边界是确定值，而 r.min_price 和 r.max_price 是右表的列，在 JOIN 语义中尚未稳定绑定。
正确写法只能是显式范围判断：
SELECT p.name, r.tier_name FROM products p JOIN price_ranges r ON p.price >= r.min_price AND p.price
-
AND连接两个独立比较，语义清晰、各数据库兼容性好 - 注意：如果区间定义为左闭右开（如
[100, 200)），就得写成p.price >= r.min_price AND p.price - NULL 值会让整个条件为 UNKNOWN，导致行被过滤——确保
min_price和max_price非空，或加WHERE r.min_price IS NOT NULL AND r.max_price IS NOT NULL
区间有重叠时，怎么只取最高优先级匹配？
现实里价格区间常重叠（比如会员价和促销价同时生效），直接 JOIN 会返回多行，但业务通常只要“最匹配”的一条——比如按 priority 字段取最大值，或按 tier_name 字典序取最新。
推荐用窗口函数去重，避免子查询嵌套：
SELECT name, tier_name
FROM (
SELECT
p.name,
r.tier_name,
ROW_NUMBER() OVER (
PARTITION BY p.id
ORDER BY r.priority DESC, r.id DESC
) AS rn
FROM products p
JOIN price_ranges r
ON p.price >= r.min_price AND p.price
-
PARTITION BY p.id保证每个商品只保留一行 -
ORDER BY r.priority DESC让高优先级排第一；加r.id DESC是防 priority 相同时结果不稳定 - 别用
GROUP BY p.id+MAX(r.priority)，那会丢失tier_name等关联字段
为什么加了索引还是慢？关键在复合索引顺序
对 price_ranges(min_price, max_price) 加索引没用——因为查询条件是 price >= min_price AND price ，数据库无法高效利用双边界索引。
真正有效的方案分两种：
- 如果
price_ranges行数少（ - 如果行数多，且区间基本不重叠，可建函数索引（PostgreSQL）：
CREATE INDEX idx_price_lookup ON price_ranges USING GIST (numrange(min_price, max_price, '[]'));，再改写 JOIN 条件为numrange(r.min_price, r.max_price, '[]') @> p.price - MySQL 用户只能靠覆盖索引 + 提前过滤：
INDEX(min_price, max_price, priority, tier_name)，让 JOIN 后能直接从索引取值，避免回表
LEFT JOIN 区间表时，NULL 结果怎么处理？
用 LEFT JOIN 是为了保留无匹配区间的商品，但容易忽略：当 r.tier_name 为 NULL 时，COALESCE(r.tier_name, 'no_match') 看似安全，其实可能掩盖数据问题。
- 先确认是否真需要 LEFT JOIN——很多场景应强制要求每商品落在某区间，用普通 JOIN + 检查漏配更稳妥
- 如果必须 LEFT JOIN，建议加校验字段：
CASE WHEN r.tier_name IS NULL THEN 'price_out_of_range' ELSE r.tier_name END - 注意：JOIN 条件里不能写
OR r.min_price IS NULL，这会让索引失效，且逻辑混乱
区间 JOIN 的核心陷阱不在语法，而在对“匹配唯一性”和“索引有效性”的误判——写完一定要用 EXPLAIN 看执行计划，尤其留意是否走了索引、是否出现 nested loop 全量扫描。
