编辑:根据原问题者的评论进行澄清,他的过程中的查询仅使用了200个中的10个列。问题是,因为底层视图包含200列,这是否仍会导致性能下降,或者优化器知道仅使用10列并忽略视图的其他190列?
谢谢,
克里斯
多余的190列肯定会影响你的性能。Adam在他的博客中对此进行了很好的解释:http://jahaines.blogspot.com/2009/06/superfluous-columns-more-than-bad-habit.html
如果视图仅限制了列但没有WHERE子句,则不确定-请参见下面的详细信息:
根据这篇文章,我推断你会遭受惩罚,因为视图不一定是使用你的10个列编译的,你可能会继承糟糕的查询计划。
测试非常容易:
运行查询
select * from myView where someNonIndexedColumn = someValue
(确保where子句中的列不在原始表的任何索引中)。
使用查询计划运行上述查询,并确保它执行表扫描。
现在,选择一些在原始表上的索引中的列,例如确保对它们的查询应使用覆盖索引。例如,在索引I1中的C1和C2。
运行
select C1, C2 from myTable where C1=x and C2=Y
并打开查询计划,确保它使用"I1"索引作为覆盖索引。
运行
select C1, C2 from myView where C1=x and C2=Y
并打开查询计划,检查它是否执行表扫描或使用I1作为覆盖索引。
我怀疑它会执行一次表扫描,那么你的答案是“对性能来说,190列是一个坏事情”- 基本上,Ryan Fonnett链接文章中的所有负面影响都适用于你的观点。
如果(不太可能)它在#5中使用覆盖索引,则thew拥有190列的事实就不相关了。
当然,这完全取决于情况。它总会产生影响。但是,如果我们谈论的是在与数据库运行在同一服务器上的应用程序,并且每个列都包含一些字节,则影响不应该太大。
另一方面,如果我们谈论的是通过网络运行客户端来访问数据库,并提取190个额外的列,例如(string*255),那么如果您的网络管理员能够抓住您,那么您就有大麻烦了。
无论哪种情况,查询如此多的不必要列并不是很优雅。为什么不调整查询,只查询所需的列呢?我假设您使用的是“select * from ...”,这会产生另一个问题:当有人更改视图(添加列或删除列)时,您的程序将被阻塞。
不要问我们,这是你应该自己测试的东西,因为答案可能高度依赖于你的数据库和视图结构以及查询结构和设备组合。尝试从视图中选择四列并与直接从涉及的表中选择它们进行比较,你将知道是否存在可测量的性能差异。如果你有多个嵌套的视图,我怀疑你会发现有可测量的差异,但如果只有一个视图,则可能不是很重要。