分段统计应先用CASE WHEN在聚合前生成虚拟字段，再在外层GROUP BY该字段进行汇总；CASE WHEN须置于聚合函数内，避免GROUP BY报错，分段边界推荐闭区间。
嵌套查询里怎么写分段统计的 CASE WHEN
分段统计汇总的核心不是靠多层 SELECT 嵌套，而是用 CASE WHEN 在聚合前把原始数据打上段标签。很多人一上来就写两层 SELECT，结果发现外层无法再按段做 SUM 或 COUNT，其实是内层没把分段逻辑固化下来。
正确做法是：最内层先用 CASE WHEN 生成虚拟字段（比如 score_level），外层再对这个字段 GROUP BY 并聚合。这样既避免子查询重复计算，也方便加 HAVING 过滤。
-
CASE WHEN必须写在聚合函数内部，不能只在外层SELECT里裸写——否则会报column must appear in the GROUP BY clause - 分段边界建议用闭区间（如
score >= 90 AND score ），避免浮点或空值漏进 <code>ELSE - 如果分段依据是字符串（如地区编码），记得用
LIKE或IN替代数值比较，否则逻辑失效
子查询嵌套时如何避免 GROUP BY 冲突
当必须用子查询（比如要先过滤再分段），常见错误是外层 GROUP BY 漏掉子查询里的非聚合字段，或者误把子查询别名当真实列名引用。
关键原则：子查询返回的结果集，就是外层的“新表”，它里面的字段名必须和子查询 AS 的别名完全一致，且外层 GROUP BY 只能用这些别名，不能用原始表字段名。
- 子查询必须带别名，例如
(SELECT ... FROM orders WHERE status = 'done') AS t - 外层
SELECT中所有非聚合字段，都得出现在GROUP BY里，且只能是t.xxx这种形式 - 如果子查询里用了
ORDER BY或LIMIT，可能被优化器忽略——分段统计不需要排序，删掉更安全
用 WITH 代替嵌套提升可读性
三层以上嵌套会让 SQL 难以调试，尤其分段逻辑分散在不同层级时。用 WITH 把分段步骤拆开，每步专注一件事，比堆 (SELECT ... (SELECT ...)) 强得多。
比如先算出每个用户的总消费和分段等级，再按等级汇总人数和平均消费——这两步逻辑清晰分离，改某一段不会牵连其他。
-
WITH中的临时结果默认不索引，大数据量时注意加MATERIALIZED（PostgreSQL）或确认执行计划是否物化 - MySQL 8.0+ 支持
WITH，但 5.7 不支持，得退回到嵌套写法 - 别在
WITH里写太多无用字段，尤其是大文本或 JSON，会拖慢中间结果传输
分段统计结果怎么补全缺失段位
默认 GROUP BY 只返回有数据的段，比如用户分数只集中在 60–80 分，90–100 段就不出现在结果里。但报表常要求“全段显示，缺数据填 0”。
解决方法不是靠 COALESCE，而是构造一个完整段位表（用 VALUES 或 UNION ALL），再和实际统计结果 LEFT JOIN。
- 段位表必须用显式枚举，不能靠
SELECT DISTINCT level FROM ...——那样还是漏段 -
LEFT JOIN后，聚合字段要用COALESCE(SUM(t.count), 0)，不能只写COALESCE(t.count, 0) - 如果段定义来自配置表（如
score_ranges），直接JOIN它就行，不用硬编码
分段逻辑一旦涉及业务规则（比如“VIP 用户折扣率按年消费分五档”），最好抽成独立视图或函数，避免每次写 SQL 都重新描述边界条件。
