CASE WHEN 是阶梯价格匹配最直接可控的解法，需用范围判断（如BETWEEN或比较符）而非简单匹配，注意边界处理与兜底ELSE；MySQL 8.0+可用LAG构造左闭右开区间优化性能；PostgreSQL可用numrange@>实现简洁语义匹配，但需GIS索引且不跨库兼容。
用 CASE WHEN 实现阶梯价格匹配最直接
多数场景下，CASE WHEN 是最可控、可读性最强的解法。它不依赖表结构变更，适合临时计算或报表字段生成。
常见错误是写成 CASE price WHEN ...（即简单匹配），但阶梯区间本质是范围判断，必须用 CASE WHEN price BETWEEN ... 或带比较符的条件。
- 注意边界：用
BETWEEN a AND b包含两端，但更推荐显式写price >= a AND price ，避免上一级区间尾端和下一级首端重叠或遗漏 - 顺序很重要：
CASE按从上到下匹配，必须把小范围（如 0–99）放前面，否则price > 0这类宽泛条件会提前截断后续判断 - 兜底别漏：最后一定要加
ELSE，否则超出所有区间的值会返回NULL，可能引发下游空值报错
SELECT
product_id,
price,
CASE
WHEN price < 100 THEN 'A'
WHEN price < 500 THEN 'B'
WHEN price < 1000 THEN 'C'
ELSE 'D'
END AS tier
FROM products;
JOIN 价格区间表更适合频繁复用或动态配置
当阶梯规则要被多个查询共用，或需运营后台随时调整时，硬编码在 SQL 里就难维护。这时应建一张 price_tiers 表：
CREATE TABLE price_tiers ( tier_code VARCHAR(10), min_price DECIMAL(10,2), max_price DECIMAL(10,2) );
关键点在于 JOIN 条件写法——不能用等值连接，得用范围匹配：
ON p.price >= t.min_price AND p.price 是基础写法，但要注意 <code>min_price和max_price是否闭合（比如是否允许max_price等于下一档min_price）- 如果区间有重叠，一条记录可能匹配多行，得加
DISTINCT或用ROW_NUMBER() OVER (PARTITION BY p.product_id ORDER BY t.min_price)取优先级最高的一档 - 性能隐患：没索引的话，范围 JOIN 在大数据量下会很慢；建议在
min_price和max_price上建复合索引，或只对min_price建索引并配合WHERE p.price >= t.min_price提前过滤
MySQL 8.0+ 可用窗口函数优化区间匹配性能
传统范围 JOIN 在数据量大时容易变慢，尤其当价格表行数远大于产品表。MySQL 8.0 起可用 LAG() 预先构造“左闭右开”区间，把范围判断转为单值查找：
- 先按
min_price排序，用LAG(max_price, 1, -1) OVER (ORDER BY min_price)得到上一行的max_price，作为当前行的lower_bound - 这样每行变成
[lower_bound, max_price]的左开右闭区间，产品价格就能用price > lower_bound AND price 精确命中一行 - 优势是避免笛卡尔积式 JOIN，但前提是区间表本身有序且无重叠；若原始区间定义混乱，预处理步骤反而增加复杂度
PostgreSQL 用 RANGE 类型和 @> 操作符最简洁
PostgreSQL 原生支持 numrange 类型，配合 @>（包含）操作符，代码干净且语义明确：
SELECT p.product_id, p.price, t.tier_code FROM products p JOIN price_tiers t ON numrange(t.min_price, t.max_price, '[)') @> p.price;
方括号语法 '[)' 表示左闭右开，天然规避边界重复问题。但要注意：
-
numrange字段需单独建索引才能加速查询：CREATE INDEX idx_tier_range ON price_tiers USING GIST (range_col) - 其他数据库没有这个能力，强行移植会导致语法报错
ERROR: type "numrange" does not exist - 如果业务需要跨数据库兼容，这条路基本走不通
区间匹配看着简单，实际最容易出问题的是边界定义和 NULL 处理——比如价格为 NULL 时，CASE 不会进任何分支，JOIN 直接丢失整行，而 numrange @> 会报错。这些细节不提前想清楚，上线后查半天才发现漏了空值校验。
