视图说到底只是 SQL 语句的一个封装，它本身并不能直接完成多层级聚合。真正要实现分层聚合，还得靠外层查询或嵌套结构来配合，否则很容易把逻辑写死，灵活性大打折扣。
为什么不能在视图里写多层 GROUP BY
SQL 的视图定义里，压根不允许出现多个 GROUP BY 层级——语法上直接报错。比如先按 region 聚合，再按 year 滚动汇总，这在视图定义中行不通。即便强行用子查询嵌套，数据库也无法下推过滤条件，索引会失效，执行计划直接退化。
- GROUP BY 必须出现在最外层 SELECT 中，视图里如果包含子查询聚合，外层再 GROUP BY 就得再嵌套一层，不然解析失败。
- MySQL 5.7 不支持 CTE，嵌套子查询一旦超过 3 层，就可能触发临时表物化，响应速度明显变慢。
- PostgreSQL 或 SQL Server 对嵌套聚合的容忍度稍高，但如果 EXPLAIN 显示 rows 增长 3 倍以上，就该考虑把某些层移到报表层了。
用视图做“宽表拼接”，把聚合留给报表层
真正可复用、易维护的做法是：视图只负责把原始事实表和维度表关联成一张逻辑宽表（比如 v_sales_enriched），字段要明确、不能用 *、不带任何 GROUP BY 或聚合函数。所有分组逻辑——按月、按地区、按产品线——由报表 SQL 自己控制。
- 例如视图定义：
SELECT s.order_id, s.amount, d.region, d.category, EXTRACT(YEAR FROM s.order_date) AS year—— 仅做关联+提取关键维度。 - 报表 SQL 再写：
SELECT region, year, SUM(amount) FROM v_sales_enriched WHERE year >= 2025 GROUP BY region, year。 - 这样改一个维度值（比如 region 分类规则变了），只需调整视图；换一种聚合口径（加个季度小计），完全不用动视图。
需要固定层级汇总？用 GROUPING SETS 或 ROLLUP 替代多视图
如果业务强要求在一张结果里同时看到地区汇总、全国总计、各月明细，别建多个视图再 UNION，直接在外层查询用标准 SQL 的多维聚合语法。
GROUPING SETS ((region), (region, year), ())—— 精准控制哪些组合要出结果。ROLLUP (year, quarter, month)—— 自动生成年→季→月→总计的路径，配合GROUPING()区分 NULL 是数据空还是聚合占位。- 注意：
CUBE在维度超过 4 个时结果行数会爆炸（2ⁿ），上线前一定要加HA VING过滤掉非必要组合。
权限和性能最容易被忽略的两个点
视图建好跑不通，大概率不是语法问题，要么是账号没被授予底层表权限，要么是聚合字段没建索引。
- 报表工具账号对视图有 SELECT 权限，但对视图里引用的 orders 表没有权限 → 报错
permission denied for table orders，注意不是视图名。 - 视图里用了
EXTRACT(MONTH FROM order_date)，但 order_date 字段没建索引 → 全表扫描，哪怕加了WHERE order_date > '2026-01-01'也无效。 - 聚合字段（比如 region）区分度低，只有三个值，又没加 WHERE 过滤，GROUP BY 会扫全量数据。这不是视图的问题，是查询设计的问题。
