视图中直接用 GROUP BY 不报语法错误但可能定义失败；必须确保 SELECT 中所有非聚合列均出现在 GROUP BY 中，否则 MySQL 5.7+/8.0（ONLY_FULL_GROUP_BY 模式）、PostgreSQL 等会报错。
视图里直接用 GROUP BY 会报错吗？
会，但不是语法错误，而是定义失败——多数数据库（如 MySQL 5.7+、PostgreSQL、SQL Server）允许在视图中使用聚合函数和 GROUP BY，但前提是必须显式指定所有非聚合列都在 GROUP BY 中，且不能有未分组的非聚合字段出现在 SELECT 列表里。
常见错误现象：ERROR 1055 (42000): Expression #1 of SELECT list is not in GROUP BY clause（MySQL 严格模式下）或 PostgreSQL 的 column must appear in the GROUP BY clause。
- MySQL 8.0 默认启用
sql_mode=ONLY_FULL_GROUP_BY，强制要求：所有SELECT中的非聚合列都必须出现在GROUP BY - PostgreSQL 更严格，连
ORDER BY中引用的非聚合列也得进GROUP BY - SQL Server 允许“隐式分组”（只要目标列功能依赖于
GROUP BY键），但不推荐依赖此行为
怎么写一个带 SUM() 和 GROUP BY 的可用视图？
关键不是“能不能”，而是“怎么写才被数据库接受”。核心是让 SELECT 列表里的每一项都明确属于聚合结果或分组依据。
假设有一张订单表 orders（user_id, amount, created_at），想按月统计用户总金额：
CREATE VIEW monthly_user_summary AS SELECT user_id, DATE_FORMAT(created_at, '%Y-%m') AS month, SUM(amount) AS total_amount FROM orders GROUP BY user_id, DATE_FORMAT(created_at, '%Y-%m');
-
user_id和DATE_FORMAT(...)都出现在GROUP BY，所以能直接选 - 别名
month是表达式，必须在GROUP BY中重复写一遍，不能只写别名 - 如果加了
ORDER BY user_id，MySQL 会报错（除非也放进GROUP BY或去掉）
视图里用 COUNT(*) 和 DISTINCT 有什么坑？
聚合本身没问题，但组合使用时容易触发逻辑歧义或性能问题。
比如想统计每个用户的订单数和去重商品数：
CREATE VIEW user_order_stats AS SELECT user_id, COUNT(*) AS order_count, COUNT(DISTINCT product_id) AS unique_products FROM orders GROUP BY user_id;
-
COUNT(DISTINCT ...)在 MySQL 5.7+ 和 PostgreSQL 中支持，但 SQLite 不支持（会报near "DISTINCT": syntax error） - PostgreSQL 对
COUNT(DISTINCT)会走哈希聚合，大数据量时内存占用高；可考虑用子查询 +GROUP BY拆解 - 如果
product_id允许为NULL，COUNT(DISTINCT product_id)会自动忽略NULL，但COALESCE(product_id, -1)这类补救写法会让视图变复杂且影响索引利用
视图聚合结果能被 WHERE 过滤，但不能 ORDER BY 排序？
可以 WHERE，但不能在视图定义里写 ORDER BY（除 SQL Server 允许配合 TOP 使用外，其他主流数据库都会忽略或报错）。
- MySQL 视图定义中写
ORDER BY会被静默丢弃，执行SELECT * FROM my_view WHERE total_amount > 1000时排序不生效 - 想固定排序，必须在查视图时加
ORDER BY：例如SELECT * FROM monthly_user_summary ORDER BY total_amount DESC - 如果视图用于 JOIN 或子查询，
ORDER BY更无效——排序只对最终结果集有意义，不影响中间计算逻辑
真正容易被忽略的是：视图一旦含聚合，就不再是“可更新视图”。你不能对它执行 INSERT / UPDATE / DELETE，数据库会直接拒绝。这点在设计数据出口或报表层时，得提前确认是否需要反向写入能力。
