索引視圖的索引基表有益嗎？

在創建索引視圖之後，我嘗試禁用基表中的所有索引，包括外鍵列的索引（約束仍然存在），視圖的查詢計劃保持不變。索引視圖的索引基表有益嗎？

它就像魔術對我來說，索引視圖將能夠如此多的優化查詢，即使沒有被索引的基表。即使在視圖上沒有任何索引，SQL Server也能夠對索引視圖的主鍵索引執行索引掃描，以獲取比使用基錶快1000倍的數據。

喜歡的東西SELECT * FROM MyView WITH(NOEXPAND) WHERE NotIndexedColumn = 5 ORDER BY NotIndexedColumn

所以前兩個問題是：

是否有索引視圖索引基表什麼好處？
當約束位於未索引列時，Sql服務器在對PK進行索引掃描時做了什麼？

然後我注意到，如果我使用全文搜索+訂單，我會在查詢計劃中看到一個表假脫機（熱衷假脫機），成本爲95％。

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

問題N°3：

有沒有我可以添加到擺脫任何操作指數？

來源

2016-11-22 Steve

檢查閱讀更深入的這樣的回答：HTTP：//stackoverflow.com/questions/40677421/how-is-blob-stored-in-an-indexed-view/40678073# 40678073 – TheGameiswar

@TheGameiswar從我已閱讀的索引視圖只存儲結果的部分子集，而不是100％重複。所以即時通訊仍然好奇，看看是否有任何好處索引原始表 – Steve

重要的是要明白，索引視圖是「物化視圖」，結果存儲在磁盤上。

所以你看到的加速是你看到存儲在磁盤上的查詢的實際結果。

回答您的問題：

1）是否有索引視圖索引基表什麼好處？

這是情境。如果您的視圖將數據平滑或具有許多額外的聚合列，則索引視圖比表格更好。如果你只是使用你的索引視圖，如 SELECT * FROM foo WHERE createdDate > getDate()那麼可能不是。

但是，如果你正在做SELECT sum(price),min(id) FROM x GROUP BY id,price然後索引視圖可能會更好。當然，你正在做一個更復雜的連接和其他高級選項的查詢。

2）什麼是Sql服務器在對PK進行索引掃描時做什麼，而約束位於未索引列？

首先，我們需要了解如何索引的集羣存儲。索引存儲在B-tree中。因此，當您在聚簇索引上搜索時，SQL Server正在樹中查找符合條件的所有值取決於您如何設置索引i。e覆蓋與非覆蓋以及您的非聚集索引如何設置將決定Pages and Extents的外觀。沒有更多關於表格結構的知識，我無法幫助你理解掃描實際上在做什麼。

3）是否有任何索引可以添加以擺脫該操作？

僅僅因爲有些事情正在考慮95％的查詢時間，並不是一件壞事。查詢時間需要加起來高達100％，所以無論你做什麼，總會有一些東西佔用大量的時間。你需要檢查的是IO讀取和查詢本身需要多少時間。

要確定這一點，您需要了解SQL Server緩存查詢結果。考慮到這一點，您可以在第一次查詢時花費很長時間，但由於數據本身緩存起來會更快。這完全取決於查詢的頻率以及您的系統設置方式。

有關indexed view

來源

2016-11-22 14:22:45 gh9

＃2我沒有索引旁邊的唯一聚集（PK）指數。如果我記得正確，它總是覆蓋。該視圖是一個非常基本的SELECT ... FROM ... INNER JOIN..ON x = y INNER JOIN..ON a = b並且查詢顯示爲有問題 – Steve

索引視圖的索引基表有益嗎？

回答

相關問題