case when 可实现区间分组，因sql无原生区间group by语法；需在select和group by中同步使用相同case表达式，用else处理边界外数据，并对null值预处理。
用 CASE WHEN 实现区间分组，别直接写 BETWEEN
SQL 没有原生的“按数值区间 GROUP BY”语法，必须靠 CASE WHEN 显式定义分段逻辑。直接在 GROUP BY 里写 BETWEEN 10 AND 20 会报错或返回空结果——因为 GROUP BY 只接受列名、表达式或序号，不接受布尔条件。
常见错误现象：GROUP BY age BETWEEN 0 AND 18 报错 ERROR: syntax error at or near "BETWEEN"；或者误用 HAVING 过滤后才发现分组没生效。
- 把区间逻辑写在
SELECT和GROUP BY两边保持一致，否则统计对不上 - 用
ELSE覆盖边界外数据（比如ELSE '其他'），避免 NULL 分组被忽略 - 如果字段可能为 NULL，先用
COALESCE(age, -1)处理，再进 CASE，否则整行会被排除
处理连续区间时，用左闭右开更安全
比如想分 “0–19 岁”、“20–39 岁”、“40+”，写成 WHEN age >= 0 AND age 看似合理，但当 age = 19.5（浮点）或存在精度误差时容易漏掉。实际应统一用左闭右开： <code>WHEN age >= 0 AND age 。
这样能避免相邻区间交叠或缝隙，尤其在数据来自不同系统、精度不一致时更可靠。
- 所有区间的判断条件用同一套边界风格，不要混用
和 <code> - 最后一档用
ELSE或显式写WHEN age >= 40，比WHEN age > 39更直观且防浮点误差 - 如果区间由配置表驱动（如动态分桶），需提前确保配置里的上下界是左闭右开格式
用数字编码代替字符串标签，提升 GROUP BY 效率
写 WHEN age 没问题，但如果后续要排序或做聚合计算（比如算各区间平均值占比），字符串分组不如数字稳定。建议先映射为整数编码，再 JOIN 标签表或用 <code>CASE 补名称。
性能影响明显：字符串比较比整数慢，尤其在大数据量 + 多分组场景下，GROUP BY bucket_id 比 GROUP BY bucket_name 快 10%–30%，且索引更友好。
- 示例：
CASE WHEN age - 若必须输出中文名，放在外层 SELECT，内层 GROUP BY 仍用
bucket_id - 注意：MySQL 8.0+ 支持 CTE，可先
WITH t AS (SELECT ..., bucket_id) SELECT ... GROUP BY bucket_id，结构更清晰
PostgreSQL / MySQL 的窗口函数替代方案慎用
有人想用 NTILE(4) OVER (ORDER BY score) 自动四等分，但这不是按业务区间分组，而是按排序位置切块——每组记录数大致相等，但区间边界不固定。比如分数全集中在 60–80 分，NTILE 仍会强行切出 0–59 的空档。
只有当你明确需要“等频分桶”（每组数量相同），而不是“等宽分桶”（每组范围相同），才考虑 NTILE 或 WIDTH_BUCKET()（PostgreSQL 内置）。多数业务统计（如年龄分段、金额档位）都属于后者。
-
WIDTH_BUCKET(score, 0, 100, 5)在 PostgreSQL 中可直接生成 0–20、20–40… 分组编号，但 MySQL 不支持，得回退到CASE - 用窗口函数做分组前，先确认需求本质：是要“控制每组人数”，还是“控制每组含义”
- 一旦用了窗口函数，就无法再在同一个查询里用
GROUP BY聚合，必须嵌套子查询，增加理解成本
CASE WHEN 配合左闭右开区间，边界定义清楚比函数炫技更重要。很多人卡在第一步——没意识到 GROUP BY 本身不能解析条件表达式，硬套语法导致全表扫不出结果。
