视图定义中允许使用GROUP BY，但必须确保所有非聚合列均出现在GROUP BY子句中或被聚合函数包裹，否则严格模式下报错；错误示例为SELECT dept_no, emp_name, COUNT(*) FROM employees GROUP BY dept_no，因emp_name未聚合也未分组。
视图定义里不能直接用 GROUP BY
SQL 标准规定，视图（VIEW）本身是**命名的查询结果集**，不存储数据，也不允许在 CREATE VIEW 语句中直接包含 GROUP BY 后跟聚合函数——除非你明确声明该视图基于一个已聚合的结果。但实际执行时，多数数据库（如 PostgreSQL、SQL Server、MySQL 8.0+）**允许创建含 GROUP BY 的视图**，前提是 SELECT 列全部满足分组合法性：即每个非聚合列必须出现在 GROUP BY 子句中，或被包裹在聚合函数里。
常见错误现象：ERROR: column "xxx" must appear in the GROUP BY clause or be used in an aggregate function（PostgreSQL）或类似提示（MySQL 5.7 strict mode / SQL Server），本质是视图定义违反了“功能依赖”规则。
- MySQL 5.7+ 默认启用
sql_mode=ONLY_FULL_GROUP_BY，强制校验；关闭它虽能绕过报错，但结果不可靠（可能返回任意行值） - PostgreSQL 严格遵循标准，不妥协；无法通过“关闭模式”来放宽限制
- SQL Server 允许创建，但后续查询若引用该视图并加额外
WHERE或ORDER BY，仍可能因底层分组逻辑暴露歧义
正确写法：GROUP BY 必须配合法则写进视图定义
视图里的 GROUP BY 不是“可选装饰”，而是定义契约。一旦写入，就决定了该视图每行代表一个分组单位，且所有输出列必须逻辑上唯一确定。
例如，想建一个部门人数视图：
CREATE VIEW dept_summary AS SELECT dept_no, COUNT(*) AS emp_count, MAX(salary) AS max_salary FROM employees WHERE status = 'active' GROUP BY dept_no;
这个定义合法，因为：
-
dept_no出现在GROUP BY中 → 可直接 SELECT -
COUNT(*)和MAX(salary)是聚合函数 → 合法输出 -
WHERE在GROUP BY前过滤，不影响分组结构
反例（非法）：
SELECT dept_no, emp_name, COUNT(*) FROM employees GROUP BY dept_no;
会失败——emp_name 未聚合也未分组，数据库无法决定该取哪条记录的姓名。
视图中嵌套 GROUP BY 的典型陷阱
很多人试图在视图里“留接口”，比如先 GROUP BY 部门，再希望外部查询按城市二次分组。这行不通：视图输出已是聚合结果，不能再对已聚合字段（如 emp_count）做 GROUP BY，除非用子查询或 CTE 包裹。
容易踩的坑：
- 把视图当普通表 JOIN：如果视图含
GROUP BY，JOIN 时可能引发笛卡尔积或重复计数（尤其和明细表关联时） - 在视图定义里用
ORDER BY：多数数据库禁止（如 PostgreSQL 报错ERROR: ORDER BY in a view is not allowed），排序应留给查询端 - 误以为视图能“延迟聚合”：视图一被引用就触发分组计算，不会等你加
HAVING才执行
替代方案：用 CTE 或内联视图更灵活
如果逻辑复杂、需要多层分组或动态条件，直接写视图反而僵硬。更可控的做法是用 CTE 或子查询封装聚合逻辑：
WITH dept_stats AS ( SELECT dept_no, COUNT(*) AS cnt, AVG(salary) AS avg_sal FROM employees GROUP BY dept_no ) SELECT d.dept_name, s.cnt, s.avg_sal FROM dept_stats s JOIN departments d ON s.dept_no = d.dept_no WHERE s.cnt > 5;
这样既避免视图维护成本，又让每次查询可自由加 WHERE、JOIN、ORDER BY，且执行计划更透明。
真正麻烦的不是语法能不能写，而是分组后丢失的明细信息是否会被下游误用——视图一旦发布，调用方很可能不知道它内部已聚合，拿它去关联原始订单表，结果数量翻倍。
