我有一个视图，该视图从一个表中提取大约200列，没有连接。使用该视图的proc仅使用其中的约10列。使用该视图时，拥有额外的190列是否会对性能产生重大影响？
编辑：仅根据原始提问者的评论进行澄清，他的proc中的查询仅使用200列中的10列。问题是，由于基础视图包含200列，还是会导致性能下降，还是优化器知道仅使用10列，而忽略了其他190个视图的知识？
谢谢，
克里斯
190多余的色谱柱肯定会影响您的性能。亚当在他的博客中对此进行了出色的解释：http://jahaines.blogspot.com/2009/06/superfluous-columns-more-than-bad-habit.html
首先，如果您的视图限制使用WHERE子句，则至少有可能会导致性能下降，因为如果它与视图自己使用的索引冲突，则无法在10列上使用良好的索引。
如果视图仅限制列而没有WHERE子句，则不确定-请参见下面的详细信息：
基于this article，我推断您将为此付出代价，因为视图不一定会使用10列进行编译，并且您可能会继承错误的查询计划。
非常容易测试：
运行查询
从myView中选择*，其中someNonIndexedColumn = someValue
（确保where子句中的列不在原始表的任何索引中。
运行上面的查询并启用查询计划，并确保它执行表扫描。
现在，在原始表的索引中选择几个列，例如确保对它们的查询应使用覆盖索引。假设索引I1中的C1和C2。
Run
从myTable中选择C1，C2，其中C1 = x和C2 = Y
启用查询计划，并确保它使用“ I1”索引作为覆盖索引。
Run
从myView中选择C1，C2，其中C1 = x和C2 = Y
启用查询计划，并检查是否执行表扫描或将I1作为覆盖索引。
[我怀疑它会进行表扫描，在这种情况下，您的回答是“ extr 190列对性能不利” –基本上，Ryan Fonnett的链接文章中的所有否定词都适用于您的视图。
[（如果（不太可能）使用＃5中的覆盖率索引，则该w具有190列的事实是不相关的。
这当然取决于。它总是会产生影响。但是，如果我们要讨论的是与数据库在同一服务器上运行的应用程序，并且每个列都包含一些字节，那么影响应该不重要。
另一方面，如果我们正在谈论通过网络运行的客户端来访问数据库，并提取190个额外的列（例如（string * 255），那么如果您的网络管理员可以抓住您的身影，您就麻烦很大。] >
无论哪种情况，查询这么多不必要的列都不是一件很优雅的事情。为什么不修改您的查询，以便仅询问所需的列。我假设您使用“ select * from ...”会产生另一个问题：当有人更改视图（添加列或删除列）时，您的程序将被阻止。
而不是问我们，这是您应该自己测试的东西，因为答案可能高度取决于数据库和视图的结构以及查询的结构和所拥有的设备组合。测试从视图中选择四列，而不是直接从涉及的表中选择它们，您将知道您是否有可衡量的性能差异。如果您在视图上堆积了视图，我怀疑您会发现可测量的差异，如果只有一个视图，可能就没什么大不了的。
对于SqlServer 2014，使用具有不必要表连接的视图仍然会降低性能。enter image description here