create view 时 group by 必须覆盖所有非聚合列，否则mysql报error 1055、postgresql直接拒绝；视图中order by无效（除非配合limit）；聚合视图不可二次聚合，且where应尽量前置以提升性能。
CREATE VIEW 时 GROUP BY 必须覆盖所有非聚合列
直接在 CREATE VIEW 中写 SELECT COUNT(*) FROM t GROUP BY x 是合法的，但只要 SELECT 列表里出现非聚合字段（比如 name、status），就必须出现在 GROUP BY 子句中，否则 MySQL 会报 ERROR 1055，PostgreSQL 直接拒绝执行。
常见错误现象：SELECT department, AVG(salary), COUNT(*) FROM employees 缺少 GROUP BY department —— 这在严格模式下必然失败，不是“可能出错”，而是语法不成立。
- MySQL 8.0+ 默认启用
sql_mode=ONLY_FULL_GROUP_BY，不能绕过 - PostgreSQL 要求
GROUP BY列表必须精确包含所有非聚合表达式 - 如果想按多个维度分组，
GROUP BY department, job_title是安全写法，但别漏掉任何一个非聚合字段
视图里用聚合函数后不能再对结果二次聚合
视图本质是保存的查询定义，不是物化结果。一旦你创建了视图 v_dept_stats 包含 AVG(salary) 和 COUNT(*)，后续再 SELECT SUM(avg_salary) FROM v_dept_stats 是错的 —— avg_salary 是每个部门的均值，对它们再求和没有统计意义，且多数数据库会报错或返回无意义值。
- 聚合视图适合做“汇总层抽象”，比如暴露各部门人数、平均薪资、最高薪资，供报表直接查
- 不要试图在视图上套
GROUP BY或嵌套聚合函数（如AVG(MAX(salary))），逻辑上不成立 - 若需跨组计算（比如“平均薪资高于全公司均值的部门”），得用子查询或 CTE，不能依赖视图本身
ORDER BY 在 CREATE VIEW 中无效，除非配合 LIMIT
标准 SQL 规定：视图定义中不允许出现 ORDER BY，因为视图是关系（无序元组集合）。MySQL 允许写但会忽略；PostgreSQL 直接报错 ERROR: ORDER BY in a view is not allowed。
- 唯一例外是加了
LIMIT的情况（如ORDER BY created_at DESC LIMIT 10），此时ORDER BY是语义必需的，MySQL 和 PostgreSQL 都接受 - 真要控制顺序，应该在查询视图时加
ORDER BY，而不是塞进视图定义里 - 别指望
CREATE VIEW v AS SELECT ... ORDER BY name能让SELECT * FROM v总是按 name 排序 —— 它不会
WHERE 条件提前过滤比在视图外过滤更高效
聚合视图的性能瓶颈常来自“先全量分组、再过滤”。比如视图定义为 SELECT dept, COUNT(*) FROM logs GROUP BY dept，而你只关心 dept = 'web'，那么数据库仍会扫描全部 logs 行做分组，哪怕最终只取一行结果。
- 如果业务中总是按某字段过滤（如
status = 'active'），把条件写进视图定义里：SELECT dept, COUNT(*) FROM logs WHERE status = 'active' GROUP BY dept - 注意：这会让视图失去通用性，但换来真实性能提升，尤其面对大表时
- 避免在视图里用
WHERE 1=1或空条件占位 —— 不解决任何问题，还干扰优化器
复杂点在于聚合视图没法“动态适配”不同过滤粒度，它一旦建好，分组维度和过滤范围就固定了。真正灵活的需求，往往得回到 CTE 或参数化查询，而不是硬塞进视图。
