SQL分段统计最稳妥方式是CASE WHEN配合GROUP BY，需统一用左闭右开等边界风格，避免漏计或重复；应前置WHERE过滤、避免在CASE中用非SARGable表达式，并优先对原始字段建索引。
用 CASE WHEN 做数值区间分组统计，核心是写对条件边界
先说结论：想稳妥地搞定SQL分段统计，CASE WHEN 配合 GROUP BY 是绕不开的标准答案。但这里有个关键细节——边界条件怎么写。边界要是写岔了，数据要么漏计，要么重复。举个例子，如果你用 score >= 100 和 score < 100 并列，那么分数正好是100的记录该归到哪边？这取决于数据库的“脾气”：MySQL默认只匹配第一个符合条件的分支，而PostgreSQL则会严格按顺序执行，可能导致意料之外的结果。
这种错误通常表现为两种现象：一是COUNT(*)的总数和原始表行数对不上；二是明明有数据落在某个区间，统计结果却显示为0。
- 统一边界风格：始终坚持「左闭右开」或「左开右闭」。推荐写成
score >= 60 AND score < 80这种形式，避免等号在相邻区间重复出现。 - 别忘了ELSE：必须给
CASE WHEN加上ELSE分支。否则，像空分数、未录入字段这类NULL值，会被直接丢弃，不参与任何分组统计。 - 过滤逻辑前置：切忌在
CASE WHEN生成分组标签的外层，再套一个WHERE去过滤原字段。这会先筛掉一部分数据，导致后续所有区间统计的基数都变小。
MySQL 和 PostgreSQL 的 CASE WHEN 行为差异要留意
不同数据库对标准SQL的支持程度有差异，CASE WHEN就是个典型。比如，MySQL允许CASE表达式出现在SELECT列中而不加GROUP BY（它实际上会隐式按整行分组），但PostgreSQL会直接报错：“column must appear in the GROUP BY clause”。所以，如果你的脚本需要兼容多种数据库，写法就得收敛到最严格的标准。
这通常发生在什么场景呢？比如你在开发一个需要同时支持MySQL和PostgreSQL的通用报表系统。
- 显式分组：所有用于分组的
CASE WHEN表达式，都必须老老实实写进GROUP BY子句。别偷懒用别名，尤其是一些旧版本的MySQL可能不支持GROUP BY alias。 - 处理NULL要规范：PostgreSQL对
NULL比较很严格，score = NULL永远返回false，必须用score IS NULL。MySQL虽然宽容些，允许= NULL的语法，但语义不一致，容易埋坑。统一使用IS NULL是最佳实践。 - 类型转换需谨慎：如果字段是字符串类型却存储着数字（比如‘95’），MySQL可能会在比较时自动做类型转换，但PostgreSQL很可能直接报类型错误。稳妥起见，提前用
CAST(score AS INTEGER)进行显式转换。
性能关键：别让 CASE WHEN 阻碍索引使用
当数据量上了千万级别，性能问题就凸显出来了。一个常见的性能陷阱是：在WHERE子句里使用CASE WHEN表达式进行过滤，例如WHERE CASE WHEN score > 85 THEN 'A' END = 'A'。这么写，数据库优化器基本无法利用字段上的索引，因为CASE是一个计算列，条件无法“下推”到索引扫描阶段。
正确的思路是把区间过滤逻辑和分组标签逻辑拆开：
SELECT
CASE
WHEN score >= 90 THEN 'A'
WHEN score >= 80 THEN 'B'
ELSE 'C'
END AS level,
COUNT(*)
FROM exam_result
WHERE score IS NOT NULL -- 先在这里过滤掉不需要的数据，减少扫描量
GROUP BY
CASE
WHEN score >= 90 THEN 'A'
WHEN score >= 80 THEN 'B'
ELSE 'C'
END;
- 考虑预计算：如果业务上经常固定查询某几个分数段（如优良中差），更优的方案是在数据写入时，就计算好并存储一个
level字段，避免每次查询都做一次全表计算。 - 索引策略：对原始字段
score建立索引就足够了。通常不需要为CASE WHEN表达式创建函数索引，除非你的查询条件本身就是复杂的表达式，比如WHERE ABS(score) > 50。 - 注意函数索引限制：虽然MySQL 8.0+和PostgreSQL都支持函数索引，但
CASE WHEN这类条件表达式通常不能直接作为函数索引的表达式。函数索引一般只支持确定性的标量函数，如ABS()、YEAR()等。
时间字段做分段统计，别直接比字符串
按时间维度分段是常见需求，但方法不对性能损耗很大。很多人会写成CASE WHEN create_time LIKE '2024-01%' THEN 'Jan'。这种方式不仅会让日期索引完全失效，而且逻辑僵化，跨年维护起来非常麻烦。
正确的做法是先用日期函数对时间进行归一化处理，再进行分段：
SELECT
CASE
WHEN YEAR(create_time) = 2024 AND MONTH(create_time) IN (1,2,3) THEN 'Q1'
WHEN YEAR(create_time) = 2024 AND MONTH(create_time) IN (4,5,6) THEN 'Q2'
ELSE 'Other'
END AS quarter,
COUNT(*)
FROM orders
GROUP BY quarter;
- 善用日期函数：使用数据库内置的日期函数会更简洁，例如MySQL的
QUARTER(create_time)，或者PostgreSQL的EXTRACT(QUARTER FROM create_time)。但务必注意时区问题：如果字段是TIMESTAMP类型，MySQL通常按系统时区转换，而PostgreSQL则按字段定义的时区转换。 - 避免字符串分组：不要使用
DATE_FORMAT(create_time, '%Y-%m')的结果作为分组键。字符串比较效率较低，且数据库无法利用原始的日期索引进行优化。 - 动态分段策略：对于“最近7天”、“上周”、“上月”这类动态时间区间，用写死的
CASE WHEN是不现实的。更可行的方案是使用多个查询UNION ALL，或者在应用层拼接好不同的WHERE条件。
说到底，分段统计的难点往往不在于SQL语法本身，而在于那些容易忽略的细节：边界定义是否严密、全集是否被覆盖、NULL值是被有意忽略还是无意丢弃，以及在大数据量表上，计算逻辑是否在不知不觉中让索引失了效。这些问题一旦出现，数据表面可能看不出明显错误，但生成的报表值已经偏离了真实情况。
