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 < 5)，导致每一行都被当成一个独立的分组，聚合功能完全失效。
- 核心要点在于，
CASE WHEN表达式必须在SELECT子句和GROUP BY子句中各写一遍，并且内容要保持严格一致，甚至连空格都不能有差异。 - 定义区间时，边界必须清晰：到底是左闭右开，还是左开右闭？所有分支必须能覆盖数据的全集，稳妥起见，建议在末尾加上
ELSE 'other'来兜底，防止数据遗漏。 - 还有一个常见的误区：别想着在
SELECT里给CASE表达式起了别名，然后在GROUP BY里直接引用这个别名。虽然 MySQL 8.0+ 支持这种写法，但 PostgreSQL、SQL Server 等数据库并不买账，一旦跨库迁移，报错就在所难免。
写 CASE WHEN 分组时，NULL 和边界值最容易翻车
在实际业务场景中，像 score 这样的字段出现 NULL 值是家常便饭。而 CASE WHEN 有个默认特性：它不会自动匹配 NULL 值，NULL 也不会进入任何 WHEN 分支。这就导致了一个隐蔽的陷阱——这部分数据会在分组统计中彻底“消失”，排查起来还相当费劲。
- 所以，必须显式处理
NULL：把WHEN score IS NULL THEN 'unknown'这样的分支放在最前面。 - 对于边界值，比如恰好等于5的
score，必须明确它归属于哪个区间：是划入 [0,5] 还是 (5,20]？只有写成WHEN score >= 0 AND score < 5和WHEN score >= 5 AND score < 20这样的形式，才能彻底消除歧义。 - 如果业务规则明确要求“5分算及格”，那就应该直接写
WHEN score >= 5 THEN 'pass'，而不是依赖区间的边界去推断。
来看一个具体的例子（统计用户积分区间的人数分布）：
SELECT
CASE
WHEN points IS NULL THEN 'missing'
WHEN points >= 0 AND points < 100 THEN 'newbie'
WHEN points >= 100 AND points < 1000 THEN 'active'
WHEN 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 THEN 'newbie'
WHEN points >= 100 AND points < 1000 THEN 'active'
WHEN 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条件里调用函数，比如WHEN YEAR(create_time) = 2023。这种写法会导致该列上的索引完全失效。
不同数据库对 CASE WHEN 分组的兼容细节
虽然 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 语句的嵌套层数就会急剧增加，变得难以维护。到了这种程度，更明智的做法是将复杂逻辑拆解到数据库视图中，或者放在应用层进行预处理，而不是在 SQL 里堆砌十几层的 WHEN 条件。
