分段统计时GROUP BY必须包含所有非聚合字段，否则报错或数据错乱；CASE WHEN表达式需直接写入GROUP BY，不可仅用别名；NULL值会进入ELSE分支，需按业务语义单独处理。
分段统计时 GROUP BY 必须包含所有非聚合字段
很多人写 CASE WHEN 分段后直接 GROUP BY，结果报错或数据错乱，核心原因是：SQL 标准要求，SELECT 中所有**未被聚合函数包裹的字段**，都必须出现在 GROUP BY 子句里。
比如你想按「订单金额区间」统计笔数，但又顺手选了 user_id —— 这时数据库不知道该用哪个 user_id 做分组代表，就会报错（如 MySQL 8.0+ 默认严格模式下提示 Expression #2 of SELECT list is not in GROUP BY clause）。
- 正确做法：只在
SELECT中放分段表达式本身，且GROUP BY与之完全一致（可写别名或重复表达式） - 错误写法：
SELECT user_id, CASE WHEN amount > 100 THEN 'high' ELSE 'low' END, COUNT(*) FROM orders GROUP BY CASE WHEN amount > 100 THEN 'high' ELSE 'low' END→user_id没进GROUP BY，报错 - 安全写法：把分段逻辑抽成子查询或 CTE，外层只查分段标签和聚合值
CASE WHEN 分段表达式必须写在 GROUP BY 里（不能只靠别名）
有人以为给 CASE WHEN 加了 AS amount_level，就能在 GROUP BY amount_level，这是错的 —— 大多数数据库（PostgreSQL、SQL Server、MySQL 5.7 兼容模式）不支持用列别名做分组依据，除非是 MySQL 5.7 以下或明确开启 sql_mode=ONLY_FULL_GROUP_BY 关闭。
本质是解析顺序：GROUP BY 在 SELECT 之前执行，此时别名还没诞生。
- 可靠写法：
GROUP BY CASE WHEN amount BETWEEN 0 AND 99 THEN '0-99' WHEN amount BETWEEN 100 AND 499 THEN '100-499' ELSE '500+' END - 更清晰写法：用子查询封装分段逻辑，外层
GROUP BY amount_level就合法了 - 注意：不同数据库对表达式重复计算的优化程度不同，复杂
CASE WHEN放两次可能轻微影响性能，但比逻辑错误重要得多
NULL 值在分段统计中会单独成一组，常被忽略
amount 字段为 NULL 时，CASE WHEN amount > 100 THEN 'high' ELSE 'low' 会落到 ELSE 分支，但如果你写的是 CASE WHEN amount > 100 THEN 'high' WHEN amount ，那 <code>NULL 就哪都不匹配，整行被过滤掉 —— 统计总数变少，却不容易察觉。
- 显式处理
NULL：CASE WHEN amount IS NULL THEN 'unknown' WHEN amount > 100 THEN 'high' ELSE 'low' END - 检查数据质量：先跑
SELECT COUNT(*) FROM orders WHERE amount IS NULL，确认是否真要纳入统计 - 某些场景下，
NULL表示“未支付”，和“0元订单”语义不同，混进ELSE可能歪曲业务含义
用窗口函数替代 GROUP BY + CASE WHEN？不推荐用于纯分段统计
看到 CASE WHEN 就想套 OVER()？那是为了排序/累计等场景。如果目标只是「每档多少条」，用窗口函数反而绕路：它不会压缩行数，而是给每行打上标签，你还得再套一层 GROUP BY 才能聚合，白白多一次扫描。
典型误用：SELECT DISTINCT amount_level, COUNT(*) OVER (PARTITION BY amount_level) FROM (...) t —— DISTINCT 和窗口函数叠加，既难读又没收益。
- 纯分段计数，老老实实用
GROUP BY + CASE WHEN - 需要同时看明细和分段汇总（比如每笔订单带所在档位的占比），才考虑窗口函数
- 注意 MySQL 8.0+ 对窗口函数支持较好，但旧版本直接报错，兼容性不如传统写法
EXPLAIN 看一眼执行计划，确认没意外触发全表扫描。 
