是一个
select * from myView
比查询本身更快地创建视图(为了拥有相同的resultSet):
select * from ([query to create same resultSet as myView])
?
我不完全清楚视图是否使用了某种缓存,使其比简单查询更快。
是一个
select * from myView
比查询本身更快地创建视图(为了拥有相同的resultSet):
select * from ([query to create same resultSet as myView])
?
我不完全清楚视图是否使用了某种缓存,使其比简单查询更快。
当前回答
编辑:我错了,你应该在上面看到马克斯的回答。
我不能从使用SQL Server的经验来说,但对于大多数数据库来说,答案是否定的。在性能方面,使用视图获得的唯一潜在好处是它可能基于查询创建一些访问路径。但是使用视图的主要原因是简化查询或标准化访问表中某些数据的方式。一般来说,您不会获得性能上的好处。不过,我可能错了。
我会举一个稍微复杂一点的例子,自己计时看看。
其他回答
我希望这两个查询的执行是相同的。视图只不过是一个存储的查询定义,视图没有缓存或存储数据。当您运行第一个查询时,优化器将有效地将其转换为第二个查询。
存储执行计划应该会有一些微不足道的好处,但可以忽略不计。
在我的发现中,使用视图比普通查询要快一些。我的存储过程大约花了25分钟(使用不同的更大的记录集和多个连接),在使用视图(非集群)后,性能稍微快了一点,但并不显著。我不得不使用一些其他的查询优化技术/方法来做出巨大的改变。
我无意中看到了这个帖子,只是想分享Brent Ozar的这篇文章,作为使用可用性组时的考虑。
布伦特·欧扎尔报道
一般来说,没有。视图主要用于方便和安全,(它们本身)不会带来任何速度上的好处。
也就是说,SQL Server 2000及以上版本确实有一个称为索引视图的特性,可以极大地提高性能,但有一些注意事项:
不是每个视图都可以被做成索引视图;它们必须遵循一组特定的指导方针,这(在其他限制中)意味着您不能包含常见的查询元素,如COUNT、MIN、MAX或TOP。 索引视图使用数据库中的物理空间,就像表上的索引一样。
本文描述了索引视图的其他优点和局限性:
You Can… The view definition can reference one or more tables in the same database. Once the unique clustered index is created, additional nonclustered indexes can be created against the view. You can update the data in the underlying tables – including inserts, updates, deletes, and even truncates. You Can’t… The view definition can’t reference other views, or tables in other databases. It can’t contain COUNT, MIN, MAX, TOP, outer joins, or a few other keywords or elements. You can’t modify the underlying tables and columns. The view is created with the WITH SCHEMABINDING option. You can’t always predict what the query optimizer will do. If you’re using Enterprise Edition, it will automatically consider the unique clustered index as an option for a query – but if it finds a “better” index, that will be used. You could force the optimizer to use the index through the WITH NOEXPAND hint – but be cautious when using any hint.