视图不存储实际数据，这是许多开发者容易忽视的关键细节。每次查询视图时，数据库都会完整展开底层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

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