SQL Server 严格要求 SELECT 中所有非聚合列必须出现在 GROUP BY 子句中，否则报错；补全 GROUP BY 可能因精度、空格、NULL 或性能问题导致统计失真，此时应改用窗口函数如 ROW_NUMBER() 获取每组最新行。
SQL Server 会直接拒绝执行，不妥协、不猜测、不 fallback —— 只要 SELECT 里有非聚合列没进 GROUP BY，就报错“列名无效”。
为什么加个字段进 GROUP BY 还可能出问题
补全 GROUP BY 看似最直白，但容易忽略字段本身的语义和分布特性：
-
datetime或datetime2字段带毫秒精度时，几乎每行值都不同，加进 GROUP BY 后分组数爆炸，SUM()或COUNT()就退化为单行统计，失去聚合意义 - 字符串字段含前后空格、大小写混用或历史改名（如
user_name曾从 "Tom" 改为 "Thomas"），会让同一逻辑主体拆成多组，统计结果虚高 - NULL 值在 GROUP BY 中被统一归为一组，但业务上 NULL 可能代表“未填写”“未知”“已注销”，混在一起会掩盖数据质量问题
- 字段越多，SQL Server 越需要做更重的哈希/排序，大表上性能下降明显，尤其当分组键无法走索引时
什么时候不该硬塞字段进 GROUP BY，而该换窗口函数
当你真正想要的是“每组一条记录 + 完整原始字段”，而不是“按某几列分组后强行拼凑一行”，GROUP BY 就是错的工具。典型场景：
- 查每个
order_id对应的最新订单详情（status,amount,created_at）——这些字段不能靠MAX(status)或ANY_VALUE()拼，因为它们来自同一行 -
order_id是主键或唯一约束，意味着整行由它决定，此时语义上不存在“歧义”，只是 SQL Server 不允许你省略声明 - 你发现补全 GROUP BY 后结果行数远超预期，或者
COUNT(*)和原表行数接近，基本可以判定分组失效
正确写法是用 ROW_NUMBER() 标记并过滤：
SELECT order_id, status, amount, created_at
FROM (
SELECT *,
ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY created_at DESC) AS rn
FROM orders
) t
WHERE rn = 1;
别用子查询先 GROUP 再 JOIN 回原表
这是常见但危险的绕开思路，例如：
SELECT g.order_id, g.total, o.status, o.created_at FROM (SELECT order_id, SUM(amount) AS total FROM orders GROUP BY order_id) g JOIN orders o ON g.order_id = o.order_id;
问题在于：JOIN 可能匹配多行（同一 order_id 多条记录），导致结果重复；若想取最新一条，又得加子查询或窗口函数，逻辑嵌套加深，可读性和维护性骤降。更糟的是，优化器可能无法有效下推过滤条件，拖慢执行。
最容易被忽略的一点：即使你靠补全 GROUP BY 让语句跑通了，只要没确认那些字段在业务逻辑上“确实单值确定”，结果就不可信——SQL Server 不替你做假设，但你也别误以为它默认帮你选了“合理”的那一个。
