SQL Server存储过程中正确使用GROUP BY需将SELECT中所有非聚合字段及表达式原样写入GROUP BY子句；聚合函数默认忽略NULL，可用ISNULL/COALESCE转0；窗口函数适合明细+统计并存场景；传参前须校验防止全表扫描。
SQL Server 存储过程中怎么正确用 GROUP BY 配合聚合函数
GROUP BY 是报表统计的骨架，但很多人一加就报 Column 'xxx' is invalid in the select list。根本原因：SQL Server 要求 SELECT 列表里所有非聚合字段，必须完整出现在 GROUP BY 子句中——不能只写别名，也不能漏掉参与计算的字段。
- 错误写法：
SELECT user_id, COUNT(*) AS cnt FROM logs GROUP BY user_id看似没问题，但如果 SELECT 里还有DATEPART(YEAR, created_at)却没放进 GROUP BY，就会失败 - 正确做法：把所有非聚合表达式原样复制进 GROUP BY，比如
GROUP BY user_id, DATEPART(YEAR, created_at) - 注意
ORDER BY可以用别名（如ORDER BY cnt），但 GROUP BY 不行；SQL Server 不支持 MySQL 那种“宽松模式” - 聚合字段别名不能用于 WHERE（WHERE 在聚合前执行），要用 HAVING 过滤聚合结果，比如
HAVING COUNT(*) > 5
存储过程里用 SUM/AVG/COUNT 时，NULL 值怎么处理才不歪数据
聚合函数默认忽略 NULL，这本是优点，但容易让人误以为“没数据=0”，实际可能是 NULL 导致整行被跳过。尤其在 LEFT JOIN 后统计子表数量时，COUNT(*) 和 COUNT(子表.id) 行为完全不同。
-
COUNT(*)统计行数，哪怕所有列都是 NULL 也算 1 -
COUNT(子表.id)只统计子表.id非 NULL 的行数，LEFT JOIN 失败时该列为 NULL，就不会计入 - 想把 NULL 当 0 用，得显式转换：
ISNULL(SUM(amount), 0)或COALESCE(AVG(rating), 0.0) - AVG 对全 NULL 列返回 NULL，不是 0；如果报表前端不做空值判断，可能直接报错或显示异常
报表场景下，窗口函数比传统 GROUP BY 更省事吗
当你要同时展示明细行和小计（比如每条订单记录旁附上该客户的订单总数），硬套 GROUP BY + JOIN 就得自连接或子查询，又慢又绕。这时候 OVER() 窗口函数就是更干净的解法。
- 例如：按客户分组计数但保留原始订单行 ——
COUNT(*) OVER (PARTITION BY customer_id) - PARTITION BY 相当于轻量级 GROUP BY，但不压缩行数；ORDER BY 在里面还能做累计求和：
SUM(amount) OVER (PARTITION BY customer_id ORDER BY order_date) - 注意 SQL Server 2005+ 支持，但旧版不支持；MySQL 8.0+、PostgreSQL 也支持，但语法细节有差异
- 性能上，简单聚合用 GROUP BY 通常更快；涉及排序或累计运算时，窗口函数逻辑清晰，但大数据量下可能多一次扫描
存储过程传参影响聚合结果？小心参数没校验导致空集或全表扫
报表存储过程常带日期范围参数，比如 @start_date 和 @end_date。如果调用时传了 NULL 或非法值，WHERE created_at BETWEEN @start_date AND @end_date 可能变成全表扫描，或者因隐式转换触发索引失效。
- 务必在开头校验参数：
IF @start_date IS NULL OR @end_date IS NULL THROW 50000, 'Date range required', 1; - BETWEEN 包含边界，但
datetime类型容易因秒级精度丢数据，建议用created_at >= @start_date AND created_at - 聚合前加
OPTION (RECOMPILE)让执行计划适配实际参数值，避免参数嗅探导致低效计划复用 - 别在 WHERE 里对字段函数化，比如
YEAR(created_at) = 2024，会跳过索引；应让参数适配字段格式
