视图过早聚合为何导致关联数据量膨胀？

视图不存数据，这是很多人容易忽略的一个关键点。每次查询视图，本质上都是在完整展开底层SQL重新执行一遍。如果视图定义里用了GROUP BY，数据库必须先盘算出所有用户和订单的匹配组合——比如10万用户，平均每人50个订单，那就是500万行中间结果——然后再进行分组聚合。而你最终其实只想要最近7天的数据，这500万行里，99%都是白算的。这就是为什么视图里先聚合再关联，反而比直接写SQL慢得多。

视图里Group By之后Join，为什么反而更慢？

问题的根源在于数据库优化器的一个固有局限——它通常无法把外层的WHERE条件下推到聚合操作之前去过滤。换句话说，你在视图外面加了个WHERE created_at > '2026-06-01'，但这个条件根本进不到orders表的扫描阶段。数据库还是会老老实实把全部订单都拉出来，做完JOIN和聚合，再回头去过滤，这中间的浪费相当惊人。

聚合列上做Join，数据膨胀的重灾区

典型的高发场景是这样的：在CDS视图或SQL视图里，先用GROUP BY算出一个“用户总消费”列，然后拿这个结果去和其他表JOIN。看起来没什么问题，实际上聚合操作并不改变关联键的语义，但优化器对此无能为力，只能先膨胀、再过滤。

• 比如视图返回了user_id和total_amount，外部查询加了个WHERE created_at > '2026-06-01'，但这个条件根本进不了orders表扫描阶段
• HANA日志里出现过单查询占了2.4GB内存，最终只返回132行的情况——根源就是中间步骤生成了388万行。不是数据本身大，而是JOIN和聚合的顺序错位导致的临时膨胀
• 某些聚合函数，比如collect_list()、median()，还可能保留全量中间数据，进一步加剧内存压力

怎么一眼看出问题出在哪？

直接看执行计划里的rows预估值就行。如果JOIN后的行数远大于最终结果行数——比如预估287641行，GROUP BY后只剩321行——那基本可以断定是路径设计出了问题。

• 用EXPLAIN或SET STATISTICS XML ON查看实际驱动表和中间行数估算
• 重点关注执行计划里有没有出现Hash Match Aggregate前面跟着一个巨大的Nested Loop或Table Scan的情况
• 一个简单粗暴的验证方法：临时绕过视图，把视图SQL拆出来，手动加上WHERE过滤条件再跑一次。如果快了很多，说明问题出在视图展开逻辑，而不是数据或索引本身

真正有效的解法不是调优，而是重构数据流动路径

性能瓶颈从来不在聚合函数本身，而是在于数据还没变少就急着去关联。你得让数据在进入JOIN之前就压缩到最小粒度。

• 把聚合提前固化：用CTE或子查询，先算SELECT user_id, SUM(amount) FROM orders WHERE created_at >= '2026-06-01' GROUP BY user_id，再和users关联
• 如果视图被多个报表复用，建物理预聚合表（比如orders_7d_summary），比每次重算稳定得多
• 临时表方案最可控：先CREATE TEMPORARY TABLE tmp_orders_agg AS ...，再ALTER TABLE ... ADD INDEX，注意字段类型要显式对齐——比如user_id是BIGINT，就别让它隐式转成INT

最容易被忽略的一点：索引对这种膨胀几乎无效。你不是在给最终结果加速，而是在给百万行中间结果排序。先让数据变少，再让它连得快，这才是正确的解决路径。