视图是否比简单查询更快？

Question

是一个

select *  from myView

比查询本身更快地创建视图(为了拥有相同的resultSet):

select * from ([query to create same resultSet as myView])

？

对于我来说,如果视图使用某种缓存使其比简单查询更快,那么我并不完全清楚.

Answer 1

是的,视图可以分配聚集索引,当它们执行时,它们将存储可以加速结果查询的临时结果.

更新:至少有三个人对此投了反对票.尽管如此,我认为他们是错的; 微软自己的文档清楚地表明,Views可以提高性能.

首先,简单的视图已经扩展到位,因此不直接有助于提高性能 - 这是真的. 但是,索引视图可以显着提高性能.

让我直接进入文档:

在视图上创建唯一的聚簇索引后,视图的结果集会立即生效并保存在数据库的物理存储中,从而节省了在执行时执行此高成本操作的开销.

其次,这些索引视图即使不被另一个查询直接引用也可以工作,因为优化器会在适当时使用它们代替表引用.

再次,文档:

索引视图可以以两种方式用于查询执行.查询可以直接引用索引视图,或者更重要的是,如果查询优化器确定视图可以替换成本最低的查询计划中的部分或全部查询,则可以选择该视图.在第二种情况下,使用索引视图而不是基础表及其普通索引.查询中不需要引用视图,查询优化器在查询执行期间使用它.这允许现有应用程序从新创建的索引视图中受益,而无需更改这些应用程序.

可在此处找到此文档以及演示性能改进的图表.

更新2:答案受到批评,因为它是提供性能优势的"索引",而不是"视图".但是,这很容易被驳斥.

我们假设我们是一个小国家的软件公司; 我将以立陶宛为例.我们在全球销售软件并将我们的记录保存在SQL Server数据库中.我们非常成功,因此,在几年内,我们拥有1,000,000多条记录.但是,我们经常需要报告销售税,我们发现我们在本国只销售了100份软件.通过创建立陶宛记录的索引视图,我们可以在MS文档中描述的索引缓存中保留所需的记录.当我们在2008年运行立陶宛销售报告时,我们的查询将搜索深度仅为7的索引(Log2(100),其中包含一些未使用的叶子).如果我们在没有VIEW的情况下做同样的事情而只依赖于表中的索引,我们必须遍历索引树,搜索深度为21!

显然,View本身将为我们提供比单独使用索引的性能优势(3倍).我试图使用一个真实世界的例子,但你会注意到一个简单的立陶宛销售清单会给我们带来更大的优势.

请注意,我只是使用一个直的b树作为我的例子.虽然我相当确定SQL Server使用了一个b树的变体,但我不知道细节.尽管如此,这一点仍然存在.

更新3:关于索引视图是否仅使用基础表上的索引的问题已经出现.也就是说,换句话说:"索引视图只是标准索引的等价物,它不会为视图提供任何新的或独特的." 如果这是真的,当然,上面的分析是不正确的!让我提供Microsoft文档中的引用,该文档说明了为什么我认为这种批评无效或无效:

使用索引来提高查询性能并不是一个新概念; 但是,索引视图提供了使用标准索引无法实现的额外性能优势.

有关于物理存储和有关指标是如何在视图中创建的文档中的其他信息数据的持久以上报价在一起,我认为这是肯定地说,索引视图是不是只是一个缓存的SQL选择恰好使用主表上定义的索引.因此,我继续坚持这个答案.

Answer 2

一般来说,没有.视图主要用于方便和安全,而不是用于提高速度.

也就是说,SQL Server 2000及更高版本确实有一个称为索引视图的特殊功能,可以极大地提高性能,但您必须按照一组非常具体的指南创建索引视图.

在线书籍中有关于视图分辨率的重要参考.

这篇文章描述了索引视图的好处和创建:

多年来,Microsoft®SQLServer™支持创建称为视图的虚拟表的功能.从历史上看,这些观点主要用于以下目的:

• 提供一种安全机制,将用户限制在一个或多个基表中的某个数据子集.

• 提供一种机制,允许开发人员自定义用户如何逻辑查看存储在基表中的数据.

使用SQL Server 2000,SQL Server视图的功能得到了扩展,从而提供了系统性能优势.可以在视图上创建唯一的聚簇索引以及非聚簇索引,以提高最复杂查询的数据访问性能.在SQL Server 2000和2005中,具有唯一聚簇索引的视图称为索引视图.

Answer 3

编辑:我错了,你应该看到Marks回答上面.

我不能说从SQL Server的经验,但对于大多数数据库,答案是否定的.从性能上看,使用视图的唯一潜在好处是它可能会根据查询创建一些访问路径.但使用视图的主要原因是简化查询或标准化访问表中某些数据的方式.一般来说,您将无法获得性能优势.不过我可能错了.

我想出一个中等更复杂的例子,并自己去看看时间.

Answer 4

至少在SQL Server中,查询计划基于查询/视图参数存储在计划缓存中,用于视图和普通SQL查询.对于两者而言,当它们在未使用足够长的时间段时从缓存中删除,并且对于其他一些新提交的查询需要空间.之后,如果发出相同的查询,则重新编译它,并将计划放回缓存中.所以不,没有区别,因为您正在重复使用相同的SQL查询和具有相同频率的相同视图.

显然,一般来说,一个视图,就其本质而言(有人认为它经常被足够使用以使其成为一个视图)通常比任何任意SQL语句更有可能被"重用".

Answer 5

如果创建实例化视图（具有模式绑定），则可能会更快。非实例化视图的执行与常规查询一样。

Answer 6

我的理解是，不久前，视图会更快，因为 SQL Server 可以存储执行计划，然后只需使用它，而不是试图在运行中找出一个。我认为现在的性能提升可能不像以前那么好，但我不得不猜测使用该视图会有一些微小的改进。

Answer 7

对于 SQL Server，视图绝对优于嵌套查询。在不知道为什么它更好的情况下（直到我阅读了 Mark Brittingham 的帖子），我运行了一些测试并且在使用视图与嵌套查询时经历了几乎令人震惊的性能改进。连续运行每个版本的查询数百次后，查询的视图版本完成了一半的时间。我会说这对我来说已经足够了。