Oracle和SQL Server在GROUP BY非聚合列处理上规则本质相同，均严格遵循SQL标准，要求所有非聚合列必须显式出现在GROUP BY中，否则报错；所谓“Oracle更宽松”实为旧版兼容模式、函数依赖误读或隐式转换等干扰所致。
Oracle 和 SQL Server 在处理 GROUP BY 非聚合列时规则**没有本质不同**——它们都严格遵循 SQL 标准，要求所有非聚合列必须显式出现在 GROUP BY 子句中，否则直接报错。
报错信息高度一致，说明语义完全对齐
你看到的“规则不同”，往往源于误判或环境配置干扰：
- SQL Server 报错：
Column 'name' is invalid in the select list because it is not contained in either an aggregate function or the GROUP BY clause - Oracle 报错：
ORA-00979: not a GROUP BY expression
两者拒绝执行的逻辑完全一致：只要 SELECT 列表里有未聚合、也未出现在 GROUP BY 中的列，就中断查询。这不是“实现差异”，而是标准强制行为。
为什么有人觉得 Oracle “更宽松”？
常见错觉来源有三个：
-
旧版 Oracle 兼容模式残留：Oracle 12c 之前某些客户端工具（如 SQL*Plus）配合特定
COMPATIBLE参数可能弱化检查，但这是历史兼容性开关，不是标准行为 -
函数依赖被误读为“自动放行”：比如
SELECT emp_id, dept_name FROM emp GROUP BY emp_id，即使dept_name由主键决定，Oracle 仍报错——它不推断函数依赖，只认语法结构 -
隐式转换掩盖问题：若
emp_id是字符串型'001'，而你在GROUP BY写了TO_NUMBER(emp_id)，但SELECT里仍是emp_id，就会因表达式不匹配报错；这不是规则松紧，是字段引用不一致
SQL Server 和 Oracle 对“分组确定性”的处理完全一致
二者都坚持一个核心原则：分组后每行输出必须能唯一映射到某组，且该映射不能靠猜测。例如：
SELECT user_id, name, COUNT(*) FROM orders GROUP BY user_id;
这条语句在 SQL Server 和 Oracle 中都会失败，因为 name 在 user_id = 100 组内可能有多个值（改名记录、大小写混用、NULL），数据库不会替你选。
你不能指望 Oracle 因为“user_id 是主键”就默许 name 出现在 SELECT 中——它和 SQL Server 一样，只看 GROUP BY 是否包含该列或其等价表达式。
真正容易被忽略的细节是数据本身
即便语法完全合规，结果仍可能出人意料：
-
NULL值在GROUP BY中被当作同一组，但业务上name IS NULL可能代表“未填写”“匿名用户”“数据缺失”，三者语义不同，却全被压进一组 - 时间字段如
created_at直接参与分组，毫秒级差异会让本该同天的记录分散成上百组；必须统一用TRUNC(created_at)（Oracle）或CAST(created_at AS DATE)（SQL Server），且SELECT和GROUP BY中的表达式必须字面一致 - 多表
JOIN后，右表字段（如orders.status）可能为NULL，若错误地将其加入GROUP BY，会把所有无订单的客户强行归为同一组，扭曲统计口径
