sql中实现非等距分组唯一通用解法是case when；round或floor仅适用于等宽区间，遇[0,5)、[5,20)等非等距区间即失效；group by中不可直接用between或布尔表达式；需在select和group by中重复相同case逻辑；可能使points索引失效。
用 CASE WHEN 实现非等距分组，别硬套 GROUP BY 数值字段
直接说结论：SQL 没有内置“按自定义区间分组”的语法糖，CASE WHEN 是唯一通用、可控、可读的解法。别试图用 ROUND() 或 FLOOR(col / 10) 硬凑——它们只适用于等宽区间，一遇到 [0,5)、[5,20)、[20,100) 这种就崩。
常见错误现象：GROUP BY col BETWEEN 0 AND 5 报错；或写成 GROUP BY (col >= 0 AND col ，结果每行都当一个分组，完全失效。
-
CASE WHEN必须写在SELECT和GROUP BY两处，且内容严格一致（连空格都不能差） - 区间边界要明确是左闭右开还是左开右闭，所有分支必须覆盖全集，建议末尾加
ELSE 'other'防漏数据 - 别把
CASE表达式起别名后在GROUP BY里引用别名——MySQL 8.0+ 支持，但 PostgreSQL、SQL Server 不支持，跨库时直接报错
写 CASE WHEN 分组时，NULL 和边界值最容易翻车
真实场景中，score 字段常有 NULL，而 CASE WHEN 默认不匹配 NULL，也不会进任何分支——结果就是这部分数据彻底消失，还查不出原因。
- 显式处理
NULL：第一个WHEN score IS NULL THEN 'unknown' - 边界值如
score = 5，要确认它属于哪个区间：是归入 [0,5] 还是 (5,20]？写成WHEN score >= 0 AND score 和 <code>WHEN score >= 5 AND score 才无歧义 - 如果业务要求“5 分算及格”，那就得写
WHEN score >= 5 THEN 'pass'，而不是靠区间推断
示例（统计用户积分区间人数）：
SELECT
CASE
WHEN points IS NULL THEN 'missing'
WHEN points >= 0 AND points = 100 AND points = 1000 THEN 'vip'
ELSE 'other'
END AS level,
COUNT(*) AS cnt
FROM users
GROUP BY
CASE
WHEN points IS NULL THEN 'missing'
WHEN points >= 0 AND points = 100 AND points = 1000 THEN 'vip'
ELSE 'other'
END;
性能影响：CASE WHEN 分组本身不拖慢，但可能让索引失效
CASE 表达式本身计算极快，瓶颈往往出在执行计划上。如果你对原始字段 points 建了索引，但 GROUP BY 用了 CASE，数据库大概率无法利用该索引做排序或聚合加速。
- 小表（WHERE points IS NOT NULL 缩减数据集再分组
- 如果分组逻辑固定且高频，可考虑加计算列（如 MySQL 5.7+ 的
GENERATED COLUMN）并为其建索引 - 避免在
CASE里调用函数，比如WHEN YEAR(create_time) = 2023—— 这会让整列失去索引能力
不同数据库对 CASE WHEN 分组的兼容细节
语法主干一致，但几个关键点容易踩坑：
- PostgreSQL 要求
GROUP BY中的表达式必须和SELECT中完全相同，包括换行和空格；MySQL 宽松些，但跨版本迁移时建议保持一致 - SQL Server 允许在
GROUP BY里直接写列序号（如GROUP BY 1），但这是反模式，可读性差，且一旦调整SELECT列顺序就崩 - SQLite 不支持在
GROUP BY中重复写完整CASE，必须用子查询或 CTE 包一层——这是少数需要绕路的情况
复杂点在于：区间逻辑看似简单，但一旦涉及时区转换、单位换算（比如把秒转成“0-5分钟”“5-30分钟”）、或多字段联合判定（如按 age 和 city_tier 组合分层），CASE 嵌套会迅速变脆。这时候宁可拆成视图或应用层预处理，也别堆砌 10 层 WHEN。
