SQL 不支持连续两个 GROUP BY，因分组是聚合起点而非嵌套操作符；需用子查询或 CTE 实现多层分组，且子查询必须加别名、仅引用内层输出字段，同时注意 NULL、零值和浮点精度处理。
为什么不能直接写两个 GROUP BY
SQL 标准禁止在同一个查询里连续写两个 GROUP BY，比如 GROUP BY dept 后再 GROUP BY size_group——语法直接报错，不是数据库兼容性问题，而是执行模型不支持。分组是聚合的起点，不是可嵌套的操作符。想实现“先按部门统计人数，再按人数区间归类”，本质是把第一层结果当数据源用，而不是让 SQL 引擎“再分一次组”。
子查询必须带别名且只引用内层字段
常见错误是子查询漏掉别名，或外层 SELECT 引用了内层没输出的列。MySQL 和 PostgreSQL 都会拒绝这种写法。
-
FROM (SELECT dept, COUNT(*) AS cnt FROM employees GROUP BY dept)必须写成FROM (SELECT dept, COUNT(*) AS cnt FROM employees GROUP BY dept) AS dept_summary，否则报Every derived table must have its own alias - 外层不能查
dept_name，除非内层SELECT明确写了它，且出现在GROUP BY中 - 内层
ORDER BY无效，删掉；LIMIT只在配合ORDER BY做 Top-N 时有用，但必须加括号包裹整个子查询
CTE 更易读，但别误以为它会自动缓存
CTE（WITH）只是逻辑命名，不是物化视图。同一 CTE 被多次引用时，多数引擎会重复执行，大表上可能比手写子查询还慢。
- 写
WITH dept_counts AS (SELECT dept, COUNT(*) AS cnt FROM employees GROUP BY dept)没问题，但后续如果写SELECT * FROM dept_counts WHERE cnt > 5 UNION ALL SELECT * FROM dept_counts WHERE cnt ，<code>dept_counts会被算两次 - PostgreSQL 支持
MATERIALIZED提示，MySQL 8.0+ 没等价机制，真要复用中间结果，得靠临时表或应用层缓存 - 多层逻辑（比如“先算部门人数 → 再筛出人数超 10 的部门 → 再统计这些部门的平均薪资”）用 CTE 分段写，比三层嵌套子查询更不容易括号错位
二次分组时最容易踩的 NULL 和除零坑
不是语法错，而是上线后突然崩——尤其当某组没数据或分母为 0 时。
-
SUM(revenue) / SUM(cost)遇到cost = 0直接报错，必须写成SUM(revenue) / NULLIF(SUM(cost), 0) - 新成立部门还没人，
COUNT(*)是 0，但SUM(salary)是NULL，后续做CASE WHEN cnt > 0 THEN avg_salary ELSE 0 END前，先用COALESCE(SUM(salary), 0)补空值 - 百分比展示前务必
ROUND(..., 4)，浮点误差会导致0.29999999999999993被前端四舍五入成 29%，而不是预期的 30%
实际跑起来才发现，最麻烦的不是写两层 SQL，而是每层都要检查 NULL、零值和精度——这些点不提前防住，线上指标一波动，就得翻日志找哪组数据突然变 NULL 了。
