case when 是sql中最通用、兼容性最好的自定义区间分桶方式，关键在于边界条件必须写准，如 score >= 60 and score

用 CASE WHEN 做数值区间分桶，核心是写对边界条件

直接说结论：SQL 里做数据范围分桶，CASE WHEN 是最通用、兼容性最好、也最容易出错的方式。关键不是“能不能写”，而是“边界写没写准”——比如 score >= 60 AND score 和 <code>score BETWEEN 60 AND 69 看似一样，但遇到浮点数或 NULL 就可能漏数据。

常见错误现象：CASE 分支没覆盖全（比如漏了 NULL 或负数），或者用 BETWEEN 时高估了整数连续性（实际字段可能是 DECIMAL(5,2)）。

• 务必显式处理 NULL：加一条 WHEN column IS NULL THEN 'unknown'
• 区间建议统一用左闭右开（>= AND ），避免 <code>BETWEEN 在非整型字段上的歧义
• 分支顺序很重要：SQL 按顺序匹配，把 IS NULL 或兜底 ELSE 放最后，但别依赖 ELSE 隐式兜底——显式写出来

CASE WHEN 分桶在不同数据库里的写法差异

语法骨架一致，但细节上容易栽跟头。比如 PostgreSQL 对 NULL 的比较更严格；MySQL 8.0+ 支持窗口函数嵌套 CASE，但老版本会报错；SQLite 不支持 THEN 'A' ELSE 'B' 后面再接表达式（必须单值）。

使用场景：报表中把用户按消费金额分层（0-99, 100-499, 500+），或日志按响应时间打标（, <code>100-500ms, >500ms）。

• PostgreSQL / Redshift：支持在 GROUP BY 里直接用带 CASE 的列别名，如 GROUP BY bucket（前提是 SELECT 中已定义 AS bucket）
• MySQL：如果 CASE 里混用字符串和数字（比如 THEN 1 和 ELSE 'N/A'），会触发隐式类型转换，导致数值被转成字符串再比大小——结果错乱
• BigQuery：支持 SAFE_CAST 套在 CASE 外层防类型崩，但别在每个 THEN 里重复写

性能陷阱：别在 WHERE 条件里对分桶列二次过滤

很多人写完分桶后，顺手加 WHERE bucket = 'high'，结果发现慢得离谱。原因很直接：数据库没法用原字段索引加速这个计算列，只能全表扫。

正确做法是把分桶逻辑反向“下推”到 WHERE，比如把 WHERE bucket = 'high' 改成 WHERE amount >= 500（前提是你知道 'high' 对应的原始区间）。

• 如果必须用分桶结果过滤，且数据量大，考虑建生成列（MySQL 5.7+ / PostgreSQL 12+）或物化视图（BigQuery / Redshift）
• 避免在 CASE 内部调用函数（如 ROUND(amount)），这会让优化器彻底放弃索引
• 测试时用 EXPLAIN 看执行计划，重点确认是否走了索引扫描（Index Scan）而不是顺序扫描（Seq Scan）

用 CASE WHEN 分桶替代 NTILE 或 WIDTH_BUCKET 的时机

NTILE 是等频分桶（每组行数差不多），WIDTH_BUCKET（Oracle/PostgreSQL）是等宽分桶（固定步长），而 CASE WHEN 是自定义规则分桶。三者完全不是替代关系，选错就白忙活。

典型误用：想按销售额前 20% 划为高价值客户，却用 CASE WHEN sales > 10000 THEN 'high'——这根本不是百分位，只是绝对值门槛。

• 要按比例分桶（Top 10%），必须先算出分位点（用 PERCENTILE_CONT 或子查询），再喂给 CASE
• WIDTH_BUCKET(x, 0, 1000, 10) 会把 x 映射到 1–10 的桶号，但它不处理 x 超出 [0,1000] 的情况（默认归到 0 或 11），而 CASE 可以显式定义“超限归为 other”
• 当业务规则复杂（比如“新客且复购率>30%”才进 A 桶），只有 CASE WHEN 能写清楚逻辑

事情说清了就结束。最常被忽略的是：分桶字段本身有没有索引、原始数据里有没有隐藏的精度问题（比如金额存的是分，但你按元写区间）、以及团队协作时没人校验 CASE 分支是否互斥且完备。