视图中GROUP BY必须显式声明且包含所有非聚合字段，否则定义阶段即被数据库拒绝；COUNT(*)与COUNT(列)语义不同，需按业务需求选择；视图不支持参数化分组，应由查询层控制时间范围等条件。
GROUP BY 必须显式写出，且所有非聚合字段都得出现在其中——否则视图创建直接失败，不是“运行时报错”，而是定义阶段就被数据库拒绝。
视图里写 GROUP BY 会报错？先看报错信息再动手
常见错误是：Expression #2 of SELECT list is not in GROUP BY clause（MySQL 8.0+）、column must appear in the GROUP BY clause（PostgreSQL）或 SQL Server 的类似提示。这不是视图“不支持聚合”，而是你写的 SELECT 违反了 SQL 标准：非聚合字段没分组，数据库无法确定该取哪一行的值。
- 检查报错里提到的列名，比如
user_name、created_at，确认它们是否真的需要出现在结果中 - 如果只是想取某个分组下的“代表值”，用
MAX(user_name)或ANY_VALUE(user_name)（MySQL）包裹，但要确保语义合理（例如该分组下user_name实际唯一） - 别依赖 MySQL 5.7 的隐式
GROUP BY行为——它已被弃用，升级后必崩
COUNT(*) 和 COUNT(列名) 在视图里差得远
LEFT JOIN 后直接写 COUNT(*) 统计子表记录数？结果全是 1。因为 COUNT(*) 数的是连接后的行数，哪怕子表没匹配行，主表行仍存在。
- 统计关联子表的实际数量，必须用
COUNT(orders.id)或COUNT(orders.order_time)（选一个非空/业务上必填的列） - 如果子表字段允许 NULL，又想统计“有数据”的行数，
COUNT(orders.status)可能漏掉 status 为 NULL 的有效订单——此时应改用SUM(CASE WHEN orders.id IS NOT NULL THEN 1 ELSE 0 END) - 视图定义里避免用
COUNT(*)做业务逻辑计数，除非你明确知道它数的是“连接后结果集的行数”
想让视图“按需分组”？别在视图里硬塞参数
SQL 标准视图不接受参数，所谓“动态分组”只能靠外部控制。把复杂逻辑塞进视图，只会让下游查询变慢、难调试、没法索引。
- 视图只做基础聚合，比如
CREATE VIEW daily_sales AS SELECT DATE(order_time) AS dt, SUM(amount) FROM orders GROUP BY DATE(order_time) - 真正需要“按月/按周切换”时，在查询视图时加
WHERE dt >= '2026-07-01'或AND EXTRACT(YEAR FROM dt) = 2026，由应用层决定范围 - 别在视图里堆
CASE WHEN切换维度（如 “当 flag=1 按天，flag=2 按品类”），这会让视图失去可预测性，也阻碍优化器选择执行计划
AVG() 和 SUM() 对全 NULL 分组返回 NULL，而不是 0；而 COUNT(列) 在整列为空时返回 0，和 COUNT(*) 完全不同。这些细节不会报错，但会让报表数字莫名对不上。 
