视图中的列数是否影响性能?

190个多余的列肯定会影响您的性能。亚当在他的博客中很好地解释了这一点: http://jahaines.blogspot.com/2009/06/superfluous-columns-more-than-bad-habit.html

首先,如果您的视图限制使用where子句,那么您可能至少会因为无法在10列上使用好的索引(如果它与视图自己使用的索引冲突)而遭受性能损失。

如果视图仅限制列,但没有where子句,则不确定-请参见以下详细信息:

基于 this article ,我推断您将受到惩罚,因为视图不一定使用您的10列进行编译,而且您可能会继承错误的查询计划。

很容易测试:

1. 运行查询

   select * from myView where someNonIndexedColumn = someValue

   (确保where子句中的列不在原始表的任何索引中)。

2. 在启用查询计划的情况下运行上面的查询,并确保它执行表扫描。

3. 现在,在原始表的索引中选择几列,例如,确保对它们的查询应该使用覆盖索引。比如,索引i1中的c1和c2。

4. 跑

   select C1, C2 from myTable where C1=x and C2=Y

   打开查询计划并确保使用“i1”索引作为覆盖索引。

5. 跑

   select C1, C2 from myView where C1=x and C2=Y

   打开查询计划并检查它是执行表扫描还是将i1作为覆盖索引。

我的怀疑是它会做一个表扫描,在这种情况下,你的回答是“Extr190列对性能是不好的”—基本上,Ryan Fonnett链接文章中的所有否定都适用于你的视图。

如果(不太可能)它在5中使用覆盖指数,那么W有190列的事实是不相关的。

当然要看情况。它总是会有影响的。但是,如果我们讨论的是与数据库运行在同一服务器上的应用程序,以及每一列都包含一些字节的列,那么这种影响应该不重要。

另一方面,如果我们讨论的是在网络上运行的客户端访问数据库,并且提取190个额外的列(如String * 255),那么如果你的网络管理员可以捕捉到你的存在,那么你就遇到了很大的麻烦。

无论哪种情况,查询这么多不必要的列都不是很优雅。为什么不调整您的查询,使它只要求所需的列。我认为您使用“select*from…”会产生另一个问题:当有人更改视图(添加列或删除列)时,您的程序将被阻止。

不要问我们,这是你应该自己测试的问题,因为答案可能高度依赖于你的数据库和视图的结构、你的查询结构和你拥有的设备组合。测试从视图中选择四列,而不是直接从所涉及的表中选择它们,您将知道是否存在可测量的性能差异。如果你的观点成堆,我想你会发现一个可测量的差异,如果只有一个观点,这可能不是什么大问题。