索引视图的索引基表有好处吗？

Question

创建索引视图后，我尝试禁用基表中的所有索引，包括外键列的索引（约束仍然存在）并且视图的查询计划保持不变。

即使没有对基表进行索引，索引视图也能够如此优化查询，这对我来说就像魔术一样。即使视图上没有任何索引，SQL Server 也能够对索引视图的主键索引进行索引扫描，检索数据的速度比使用基表快 1000 倍。

类似SELECT * FROM MyView WITH(NOEXPAND) WHERE NotIndexedColumn = 5 ORDER BY NotIndexedColumn

所以前两个问题是：

1. 索引视图的基表索引有什么好处？
2. 当约束位于未索引的列上时，Sql server 在 PK 上执行索引扫描时在做什么？

然后我注意到，如果我使用全文搜索 + order by，我会在查询计划中看到一个 table spool（eager spool），成本约为 95%。

查询看起来像SELECT ID FROM View WITH(NOEXPAND) WHERE CONTAINS(IndexedColumn, '"SomeText*"') ORDER BY IndexedColumn

问题 3：

1. 是否可以添加任何索引来摆脱该操作？

Answer 1

重要的是要了解索引视图是“物化视图”并且结果存储在磁盘上。

因此，您看到的加速是您看到的存储到磁盘的查询的实际结果。

回答您的问题：

1) 索引视图的基表有什么好处吗？

这是情境性的。如果您的视图正在展平数据或有许多额外的聚合列，那么索引视图比表更好。如果您只是像这样使用索引视图 SELECT * FROM foo WHERE createdDate > getDate() 那么可能不会。

但是如果你在做SELECT sum(price),min(id) FROM x GROUP BY id,price 那么索引视图可能会更好。当然，您正在使用连接和其他高级选项进行更复杂的查询。

2) 当约束在未索引的列上时，Sql server 对 PK 进行索引扫描时在做什么？

首先我们需要了解聚集索引是如何存储的。索引存储在B-tree 中。因此，SQL Server 会在树中查找所有符合您的条件的值当您在聚集索引上搜索时取决于您设置索引的方式，即覆盖与非覆盖以及非聚集索引的方式设置将确定Pages and Extents 的外观。如果没有更多关于表结构的知识，我无法帮助您了解扫描实际在做什么。

3）我可以添加任何索引来摆脱该操作吗？

仅仅因为某事占用了 95% 的查询时间，这并不意味着这是一件坏事。查询时间需要加起来达到 100%，所以无论你做什么，总会有一些事情占用很大比例的时间。您需要检查的是 IO 读取以及查询本身需要多少时间。

要确定这一点，您需要了解 SQL Server 缓存查询结果。考虑到这一点，第一次查询可能会花费很长时间，但之后由于数据本身被缓存，因此会更快。这完全取决于查询的频率以及系统的设置方式。

更深入地阅读indexed view