GROUP BY需先用CASE或CTE将业务规则转为可分组字段，避免错误；聚合应留在SQL层，禁用循环查SUM；优先用窗口函数替代JOIN子查询；GROUP BY字段顺序影响索引使用。
GROUP BY 不能直接按业务规则分组，得先用 CASE 或 CTE 拆出分组键
SQL 的 GROUP BY 只认字段或表达式值，不理解“上半月/下半月”“VIP/普通用户”这类业务概念。硬写 GROUP BY status = 'active' 会报错——它不是列，也不是标量表达式（除非加括号和别名）。必须先把规则转成可分组的值。
常见错误现象：ERROR: column "xxx" must appear in the GROUP BY clause or be used in an aggregate function，本质是 SELECT 里用了未聚合又未出现在 GROUP BY 中的逻辑字段。
- 用
CASE WHEN在 SELECT 和 GROUP BY 里同步构造分组维度，比如按订单金额分档：CASE WHEN amount >= 1000 THEN 'high' ELSE 'low' END AS level - 更清晰的做法是用 CTE 预计算分组键，避免重复写 CASE；CTE 结果可读性高，也方便后续加 WHERE 过滤
- 注意 NULL 处理：CASE 默认不匹配时返回 NULL，若业务上 NULL 是有效分组，需显式写
ELSE 'unknown'，否则可能被聚合漏掉
存储过程里写聚合逻辑，别在循环里逐条查再 SUM
有人把“统计每个部门当月销售额”写成：先查出所有部门 ID，再用 WHILE 循环，对每个部门执行一次 SELECT SUM(sales) FROM orders WHERE dept_id = @id AND month = @m。性能崩盘，IO 爆增，还容易锁表。
正确路径是把聚合留在 SQL 层，让引擎一次性完成。存储过程只负责传参、组装条件、调用结果集。
- 用
INSERT INTO #temp SELECT dept_id, SUM(sales) ... GROUP BY dept_id把聚合结果暂存临时表，后续再 JOIN 或加工 - 参数要防注入：别拼接
@sql = 'SELECT ... WHERE status = ''' + @status + ''''；改用参数化查询，或严格校验@status是否在白名单（如IN ('active', 'inactive')） - 如果聚合后还要做“取 Top 3 部门”，别在存储过程里用游标排序；直接在 SELECT 后加
ORDER BY total_sales DESC OFFSET 0 ROWS FETCH NEXT 3 ROWS ONLY（SQL Server 2012+）或TOP 3
窗口函数替代部分 GROUP BY + JOIN 场景，避免自连接爆炸
想给每条订单加“该客户历史总消费额”，有人写成：主表 LEFT JOIN (SELECT customer_id, SUM(amount) FROM orders GROUP BY customer_id) t ON o.customer_id = t.customer_id。数据量大时，子查询可能被反复执行，JOIN 后行数不变但逻辑复杂。
窗口函数能原地算出聚合值，不改变行数，也不引入额外关联。
- 用
SUM(amount) OVER (PARTITION BY customer_id)直接生成每行对应的客户总消费，比子查询更稳、更易读 - 注意 PARTITION BY 和 ORDER BY 组合：加了
ORDER BY order_date就变成累积和（running total），不是全量聚合；要全量就得去掉 ORDER BY - 某些旧版 SQL Server（2005）不支持窗口函数，此时只能退回到子查询；但 2012+ 建议优先用窗口，尤其涉及多层分组嵌套时
GROUP BY 字段顺序影响索引利用，但不影响结果语义
GROUP BY a, b 和 GROUP BY b, a 返回结果一样，但底层执行计划可能天差地别。如果表上有索引 IX(a,b)，前者能走索引扫描，后者大概率触发排序（Sort）操作，CPU 和内存开销陡增。
这不是 bug，是优化器基于索引结构做的选择。实际跑慢了，先看执行计划里有没有红色警告“Missing Index”或高占比的 Sort 算子。
- 建复合索引时，把高频用于 GROUP BY 的字段放前面，尤其是等值条件（
=）字段优先于范围条件（>,BETWEEN） - 别为“看着顺眼”调整 GROUP BY 字段顺序；以索引定义和 WHERE 条件为依据，例如 WHERE 有
WHERE status = 'paid'，那索引应为(status, created_month)，GROUP BY 也按此顺序写 - SQL Server 中，
GROUP BY后字段若含计算列（如YEAR(order_date)），记得该列已建好持久化计算列并索引，否则无法走索引
业务分组规则越复杂，越容易在 CASE 分支遗漏边界、在窗口函数里错配 PARTITION 和 ORDER、或在存储过程中把聚合逻辑下推到应用层。这些地方不报错，但一到数据量上来就卡住，而且很难一眼定位。
