是的 ，可以为视图分配聚簇索引，并且当它们这样做时，它们将存储临时结果，这些结果可以加快结果查询的速度。

更新：至少三个人对我投了反对票。出于所有应有的尊重，我认为它们是错误的；Microsoft自己的文档非常清楚地表明Views可以提高性能。

首先，将简单的视图扩展到适当的位置，因此不会直接有助于提高性能-确实如此。 但是， 索引视图可以 大大 提高性能。

让我直接转到文档：

在视图上创建唯一的聚集索引后，视图的结果集将立即实现并保存在数据库的物理存储中，从而节省了在执行时执行此昂贵操作的开销。

其次， 即使没有被另一个查询直接引用 这些索引视图 ，它们也 可以工作，因为优化器将在适当的时候使用它们代替表引用。

同样，文档：

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

可以在此处找到该文档以及展示性能改进的图表。

更新2： 批评该答案的依据是，提供性能优势的是“索引”，而不是“视图”。但是，这很容易被驳斥。

让我们说我们是一个小国的软件公司；我将以立陶宛为例。我们在全球范围内销售软件，并将记录保存在SQL
Server数据库中。我们非常成功，因此在短短几年内，我们已拥有超过1,000,000条记录。但是，出于税收目的，我们经常需要报告销售情况，我们发现在本国仅售出了100份软件。通过仅创建立陶宛记录的索引视图，我们可以将所需的记录保存在MS文档中所述的索引缓存中。当我们运行2008年立陶宛销售报表时，我们的查询将搜索深度仅为7的索引（Log2（100）带有一些未使用的叶子）。如果我们要在没有VIEW的情况下执行相同的操作，而只是依靠表中的索引，则必须遍历索引深度为21的索引树！

显然，与单独使用索引相比，视图本身将为我们提供3倍的性能优势。我尝试使用一个真实的示例，但您会注意到，立陶宛销售的简单清单将为我们提供更大的优势。

请注意，在我的示例中，我仅使用一个直的b树。尽管我相当确定SQL Server使用了b树的某种变体，但我不知道细节。尽管如此，这一点仍然成立。

更新3：
关于索引视图是否仅使用放置在基础表上的索引的问题已经浮出水面。也就是说，换句话说：“索引视图仅相当于标准索引，它对视图没有提供任何新的或唯一的。”
当然，如果这是真的，那么以上分析将是错误的！让我提供Microsoft文档中的一句话，以说明为什么我认为这种批评无效或正确：

使用索引来提高查询性能并不是一个新概念。但是，索引视图提供了使用标准索引无法实现的其他性能优势。

连同以上有关物理存储中数据的持久性的引用以及文档中有关如何在Views上创建索引的其他信息一起，我认为可以肯定地说，索引视图 不仅
是使用SQL缓存的SQL Select。主表上定义的索引。因此，我继续支持这个答案。