我想询问在SQL 2012及更高版本中使用视图时的性能。假设我有一个涉及多个连接等的复杂查询。假设由于查询的复杂性和记录的数量，此查询需要10分钟才能执行。
我希望为最终用户提供一个简单的“表”，因此我选择使用上面的查询创建一个视图。我喜欢使用视图的概念，因为根据我的理解，您不会复制数据，而是创建一个“虚拟表”，它只是引用存储它的数据。与使用相关数据创建第二个物理表相比，这显然是有效的。但我担心表现。
如果用户希望使用视图选择此数据的子集，是否需要运行整个查询以首先创建视图，然后从该视图中提取所需数据的子集？换句话说，对于最终用户，他们是否会在10分钟以上才能获得所需的数据？
答案 0 :(得分：4)
引用视图的查询已经过优化＆＃34;作为一个整体＆＃34;没有真正的痕迹，根本没有任何观点。
如果优化器正在正常工作，它不会先计算视图的结果，然后对其进行过滤 - 它会将谓词推得很远，而且＃34;内部＆＃34;视图和基表，如果可能的话。
另一种思考它的方式，而不是一个＆＃34;虚拟表＆＃34;，而是作为一个＆＃34;子查询宏＆＃34; - 在优化发生之前有效地将子查询插入到引用查询中，就像在编译和优化发生之前宏可能会在其他编程语言中扩展一样。
答案 1 :(得分：1)
这取决于您对视图所做的操作。如果最终用户根据表达式创建了影响列的where子句，例如转换为不同的数据类型或大小写逻辑以更改列值，在应用过滤器谓词之前，需要实现整个视图。这可能会大大减慢查询处理速度。
如果最终用户性能是一个重要问题且基础数据不经常更改，则可以在视图上放置索引。只要基础表内容发生更改，SQL Server就会执行视图并将结果存储在索引中。对视图的查询将使用索引而不是再次执行视图的定义。您必须支付视图结果集的存储成本，但这可以是提高相对静态数据的性能的有效方法。
但是，我要研究的第一件事是为什么查询需要10分钟才能执行。