在做用户画像、销售报表或者运营分析的时候，我们经常需要把连续的数值切分成若干区间，比如把消费金额分成低、中、高三个层级，把年龄划分成不同人群段。这种操作通常叫做分桶或者分段。在SQL里实现分桶最直接的工具就是CASE语句，但很多人只会把阈值硬编码在SQL里，一旦业务方说"把高档的门槛从1000调到800"，就得改代码重新上线。其实只要把阈值设计成变量或者配置，就能实现真正的动态分组。下面我们从基础写法讲起，逐步深入到动态阈值的实现方案。
一、CASE语句实现分桶的基本原理
CASE语句本质上是一个条件表达式，它按照从上到下的顺序依次判断WHEN条件，命中第一个满足的分支就返回对应的结果，后面的条件不再判断。这个特性对分桶来说非常关键：如果你的区间存在重叠，WHERE条件的书写顺序会直接决定数据落到哪个桶里。
先看一个最基础的静态分桶写法，假设我们有一张用户消费表user_spending，需要按金额分成三档：
SELECT
user_id,
amount,
CASE
WHEN amount >= 1000 THEN '高消费'
WHEN amount >= 500 THEN '中消费'
WHEN amount >= 0 THEN '低消费'
ELSE '无效数据'
END AS consume_level
FROM user_spending;
这段代码有几个细节值得注意。第一，条件必须按阈值从大到小（或者从小到大）严格排序书写，如果把amount >= 500放在第一个，那么金额为2000的记录也会被分到中消费档，因为500这个条件先命中了。第二，ELSE分支用来兜底处理NULL或者负数，如果不写ELSE，不满足任何条件时CASE会返回NULL，这往往不是我们想要的结果。第三，CASE返回的别名列可以直接用于GROUP BY，这样就能统计每个桶的数量：
SELECT
CASE
WHEN amount >= 1000 THEN '高消费'
WHEN amount >= 500 THEN '中消费'
ELSE '低消费'
END AS consume_level,
COUNT(*) AS user_count,
ROUND(AVG(amount), 2) AS avg_amount
FROM user_spending
GROUP BY consume_level
ORDER BY MIN(amount);
这里用GROUP BY直接引用了CASE的别名，MySQL、PostgreSQL等主流数据库都支持这种写法。但如果需要在GROUP BY里重复写整段CASE表达式（比如Oracle的老版本），建议用子查询先算出分桶列再分组，可读性更好。
二、用变量实现动态阈值的分桶
静态写法的问题在于阈值被写死在SQL文本里，调整区间就要改SQL。更灵活的做法是把阈值提取成变量，SQL本身不需要任何改动，只要改变量的值就能切换分桶口径。不同数据库传变量的方式不一样，下面分别演示。
MySQL中可以在存储过程或者预处理语句里用用户变量：
SET @high_threshold := 1000;
SET @mid_threshold := 500;
SELECT
CASE
WHEN amount >= @high_threshold THEN '高消费'
WHEN amount >= @mid_threshold THEN '中消费'
ELSE '低消费'
END AS consume_level,
COUNT(*) AS user_count
FROM user_spending
GROUP BY consume_level;
如果想调整口径，只需要重新SET变量的值。在应用层（比如Java、Python）拼接SQL时，也可以用占位符传参，效果相同。PostgreSQL则可以使用匿名代码块配合变量：
DO $$
DECLARE
v_high NUMERIC := 1000;
v_mid NUMERIC := 500;
BEGIN
-- 业务逻辑中引用 v_high、v_mid 作为分桶阈值
RAISE NOTICE '高消费阈值: %, 中消费阈值: %', v_high, v_mid;
END $$;
还有一种更工程化的方案，是把阈值维护在配置表里，通过JOIN的方式实现完全动态的分桶。这种做法的好处是业务人员可以直接改配置表的数据，不用动任何SQL代码：
-- 阈值配置表
CREATE TABLE bucket_config (
id INT PRIMARY KEY,
bucket_name VARCHAR(50),
min_value NUMERIC,
max_value NUMERIC,
sort_order INT
);
INSERT INTO bucket_config VALUES
(1, '低消费', 0, 499.99, 1),
(2, '中消费', 500, 999.99, 2),
(3, '高消费', 1000, NULL, 3);
-- 通过JOIN实现动态分桶
SELECT
c.bucket_name,
COUNT(u.user_id) AS user_count
FROM user_spending u
LEFT JOIN bucket_config c
ON u.amount >= c.min_value
AND (u.amount < c.max_value OR c.max_value IS NULL)
GROUP BY c.bucket_name
ORDER BY MIN(c.sort_order);
配置表方案的区间用左闭右开（或自行约定）的min和max来定义，最大区间用一个NULL表示无穷大。要注意区间必须首尾衔接且不重叠，否则一条记录可能匹配到多个桶或者一个桶都匹配不到。LEFT JOIN可以保证无匹配的数据不被丢弃，便于排查脏数据。
三、边界值处理与常见坑点
分桶看似简单，实际踩坑的人不少，主要集中在边界值的归属问题上。比如阈值是500时，恰好等于500的记录应该算高档还是中档？>=和>一字之差，结果就完全不同。建议在团队内部统一约定区间口径，常用的数学写法是左闭右开区间[500, 1000)，对应SQL就是amount >= 500 AND amount < 1000。
NULL值是另一个高频坑。在SQL中NULL和任何数值比较结果都是UNKNOWN，所以WHEN amount >= 500对NULL不成立，NULL会一路穿透到ELSE分支。如果ELSE写的是'低消费'，NULL就被错误地归到了最低档，统计结果会产生偏差。正确做法是先显式处理NULL：
SELECT
CASE
WHEN amount IS NULL THEN '无消费记录'
WHEN amount >= 1000 THEN '高消费'
WHEN amount >= 500 THEN '中消费'
ELSE '低消费'
END AS consume_level,
COUNT(*) AS user_count
FROM user_spending
GROUP BY consume_level;
性能方面也要留意。CASE本身计算开销很小，但如果分桶列用于过滤或者JOIN条件，数据库可能无法有效利用索引。数据量大的场景下，可以考虑先在子查询里用索引列过滤出目标范围，再在外层做分桶统计；或者把分桶结果物化到一张汇总表里，通过定时任务刷新，避免每次查询都全表扫描。
另外，当桶的数量很多（比如十几个区间）时，CASE语句会变得冗长难维护。这时配置表JOIN方案的优势就体现出来了，新增一个桶只需插入一行配置。如果数据库支持自定义函数（如PostgreSQL的PL/pgSQL），也可以把分桶逻辑封装成函数get_bucket(amount)，SQL主体保持简洁。总体来说，三五个固定的桶用CASE足够，桶多或者口径经常变，就交给配置表来管理，两者结合才能兼顾灵活性和可维护性。