视图比简单查询更快吗？
是一个
select * from myView 比查询本身创build视图更快（为了有相同的结果集）：
select * from ([query to create same resultSet as myView])
？
对于我来说，如果视图使用某种caching，与简单的查询相比更快，这并不是完全清楚。
是的 ，视图可以分配一个聚集索引，当他们这样做时，他们将存储临时结果，这可以加速生成的查询。
更新：至less有三个人在这个投票。 在所有的应有的尊重，我认为他们是错的; 微软自己的文档清楚地表明Views可以提高性能。
首先，简单的观点得到扩展，所以不直接有助于提高绩效 – 这是事实。 但是，索引视图可以显着提高性能。
让我直接进入文档：
在视图上创build唯一的聚簇索引之后，视图的结果集立即实现并保存在数据库的物理存储中，从而节省了在执行时执行这种代价高昂的操作的开销。
其次， 即使这些索引视图没有被另一个查询直接引用 ，这些索引视图也可以工作，因为在适当的时候，优化器将使用它们来代替表引用。
再次，文件：
索引视图可以以两种方式用于查询执行中。 查询可以直接引用索引视图，或者更重要的是，如果查询优化器确定视图可以代替成本最低的查询计划中的部分或全部查询，则可以select视图。 在第二种情况下，使用索引视图而不是基础表及其普通索引。 查询不需要在查询中引用查询优化器在查询执行期间使用它。 这使现有的应用程序可以从新创build的索引视图中受益，而无需更改这些应用程序。
这个文档以及演示性能改进的图表可以在这里find。
更新2：答案是在提供性能优势的“索引”而不是“视图”的基础上被批评的。 但是，这很容易被驳倒。
让我们说，我们是一个小国的软件公司， 我将以立陶宛为例。 我们在全球销售软件，并将logging保存在SQL Server数据库中。 我们非常成功，所以在几年内，我们有超过100万条logging。 但是，我们经常需要报告销售税，因此我们发现我们在本国只销售了100份软件。 通过创build立陶宛logging的索引视图，我们可以将索引caching中所需的logging保存在MS文档中。 当我们在2008年运行我们的立陶宛销售报告时，我们的查询将search深度仅为7的索引（带有一些未使用的叶子的Log2（100））。 如果我们在不使用VIEW的情况下做同样的事情，并且只依靠表中的索引，那么我们就必须遍历search深度为21的索引树！
显然，视图本身将为我们提供性能优势（3倍），而不仅仅是简单地使用索引。 我试图用一个真实世界的例子，但是你会注意到一个简单的立陶宛销售清单会给我们带来更大的优势。
请注意，我只是使用了一个直的b-tree作为我的例子。 虽然我相当确定SQL Server使用B树的一些变体，但我不知道细节。 但是，这一点是成立的。
更新3：关于索引视图是否使用放置在基础表上的索引问题已经出现。 也就是说，“索引视图只是一个标准索引的等价物，它并没有为视图提供任何新的或独特的东西。” 如果这是真的，当然，那么上面的分析将是不正确的！ 让我从微软文档中提供一个引用来certificate为什么我认为这个批评是无效的或不正确的：
使用索引来提高查询性能不是一个新概念; 但是，索引视图提供了使用标准索引无法实现的额外性能优势。
再加上上面关于物理存储中的数据持久性和文档中有关如何在视图上创build索引的其他信息，我认为可以肯定地说，索引视图不仅仅是一个caching的SQL Select，恰好使用在主表上定义的索引。 因此，我仍然坚持这个答案。
一般来说，没有。 视图主要用于方便和安全，而不是为了提高速度。
也就是说，SQL Server 2000及更高版本有一个称为索引视图的特殊function， 可以大大提高性能，但是您必须遵循一组非常具体的指导原则来创build索引视图。
联机丛书在视图parsing方面有一个重要的参考。
以下是描述索引视图的优点和创build的文章：
多年来，Microsoft®SQL Server™已经支持创build称为视图的虚拟表格的能力。 历史上，这些观点符合这些主要目的：
提供一种安全机制，将用户限制在一个或多个基表中的某个数据子集。
提供一种机制，允许开发人员定制用户如何逻辑地查看存储在基表中的数据。
使用SQL Server 2000，SQL Server视图的function已扩展，以提供系统性能优势。 可以在视图上创build唯一的聚簇索引，也可以在非聚簇索引上创build唯一的聚簇索引，以提高最复杂查询的数据访问性能。 在SQL Server 2000和2005中，具有唯一聚集索引的视图称为索引视图。
至less在SQL Server中，查询计划基于查询/查看参数存储在计划caching中，以用于视图和普通SQL查询。 对于这两者，当它们在未被使用足够长的时间段时从caching中被丢弃，并且对于其他一些新提交的查询需要空间。 之后，如果发出相同的查询，则重新编译并将计划放回到caching中。 所以不，没有区别，因为您正在重复使用相同的SQL查询和相同频率的相同视图。
很显然，总的来说，一种非常自然的观点（有人认为这个观点经常被用来视为一个观点）通常比任何一个任意的SQL语句更可能被“重用”。
编辑：我错了，你应该看到上面的标记答案。
我不能从SQL Server的经验，但对于大多数数据库的答案是否定的。 您从使用视图获得的唯一潜在好处是性能，因为它可能会根据查询创build一些访问path。 但使用视图的主要原因是简化查询或标准化访问表中某些数据的方式。 一般来说，你不会得到一个性能好处。 不过，我可能是错的。
我会想出一个适度更复杂的例子和时间自己看看。
如果创build一个实例化视图（ 使用模式绑定 ），速度可能会更快。 非物化视图就像常规查询一样执行。
我的理解是，一段时间后，一个视图会更快，因为SQL Server可以存储一个执行计划，然后使用它，而不是试图找出一个dynamic。 我认为现在的performance收益可能不如以前那么好，但是我不得不猜测，使用这个观点会有一些微小的改善。
我期望这两个查询执行相同的。 一个视图只不过是一个存储的查询定义，没有为视图caching或存储数据。 当你运行它时，优化器将有效地将你的第一个查询转换成你的第二个查询。
绝对是一个视图比SQL Server的嵌套查询更好。 不知道为什么它更好（直到我读了Mark Brittingham的post），我运行了一些testing，并且在使用视图和嵌套查询时遇到了几乎令人震惊的性能改进。 在连续数百次运行查询的每个版本之后，查询版本的查询在一半时间内完成。 我想说这对我来说已经足够了。
没有实际的不同，如果你阅读BOL，你会发现永远不会有你的简单的旧的SQL SELECT * FROM X利用计划caching等。
在执行计划存储应该有一些微不足道的收益，但它可以忽略不计。
视图的目的是反复使用查询。 为此，SQL Server，Oracle等通常会提供视图的“caching”或“编译”版本，从而提高其性能。 一般来说，这应该比“简单”查询执行得更好，但如果查询真的很简单，好处可能是微不足道的。
现在，如果你正在做一个复杂的查询，创build视图。
在我的发现中，使用视图比普通查询要快一点。 我的存储过程花了大约25分钟（使用不同的大型logging集和多个连接），使用视图（非群集）后，性能只是稍微快一点，但却不显着。 我不得不使用一些其他的查询优化技术/方法，使其发生巨大的变化。
这一切都取决于情况。 MS SQL索引视图比普通视图或查询快，但索引视图不能在镜像数据库环境（MS SQL）中使用。
任何types的循环中的视图都会导致严重的减速，因为每次在循环中调用视图时都会重新填充视图。 与查询相同。 在这种情况下，使用＃或@来保存数据循环的临时表比视图或查询快。
所以这一切都取决于情况。
从视图或从表中select不会太有意义。
当然，如果View没有不必要的连接，字段等，您可以检查用于改善View性能的查询，连接和索引的执行计划。
您甚至可以在视图上创build索引以获得更快的search要求。 http://technet.microsoft.com/en-us/library/cc917715.aspx
但是，如果你正在search'％…％'比sql引擎不会从文本列的索引中受益。 如果您可以强制用户进行search，比如“…％”，那么search速度会很快
在asp论坛上提到的答案： https : //forums.asp.net/t/1697933.aspx? Which+is+faster+when+using+SELECT+query+VIEW+or+Table+
