SQL Server索引視圖以（物化視圖）及索引視圖與查詢重寫

 

本文出處：http://www.cnblogs.com/wy123/p/6041122.html 

 

　　經常聽Oracle的同學說起來物化視圖，物化視圖的作用之一就是可以實現查詢重寫，聽起來有一種高大上的感覺，
　　SQL Server也有類似於Oracle物化視圖的功能，只不過叫做索引視圖。
　　說實話，還是物化視圖聽起來比較合適，與普通視圖比，物化視圖就是直接將數據存儲起來了
　　SQL Server中的索引視圖也具有查詢重寫的功能，
　　所謂的查詢重寫，就是如果符合條件的數據在索引視圖上，並且查詢列都包含在在索引視圖上，此時可以直接通過查詢索引視圖來替代基於原始表的查詢

 

依舊慣例，先上代碼做一個測試環境

--創建兩張表，一張表頭，一張明細，僅僅作為DEMO使用
CREATE TABLE HeadTable
(
    HeadId      INT PRIMARY KEY  ,
    HeadInfo    VARCHAR(50)      ,
    DataStatus  TINYINT          ,
    CreateDate  Datetime
)
GO

CREATE TABLE DetailTable
(
    HeadId      INT   　　　　　　　　,
    DetailId    INT identity(1,1) PRIMARY KEY ,
    DatailInfo  VARCHAR(50)
)
GO

--寫入數據
DECLARE @i int = 0
WHILE @i<200000
BEGIN
    INSERT INTO HeadTable values (@i,NEWID(),RAND()*10,GETDATE()-RAND()*100)
    INSERT INTO DetailTable(HeadId,DatailInfo) VALUES (@i,NEWID())
    SET @i=@i+1
END
GO

 

 

索引視圖創建

那么如何創建索引視圖呢？語法上跟創建普通視圖差別不大，但是不允許出現select *,表名上要加上Scheme，因為這里不是專門說索引視圖的，細節就不多說了。

CREATE VIEW V_IndexViewTest WITH SCHEMABINDING
AS
    SELECT H.HeadId,H.CreateDate,H.DataStatus,D.DetailId,D.DatailInfo
    FROM dbo.HeadTable H INNER JOIN 
                dbo.DetailTable D ON H.HeadId = D.HeadId
    WHERE H.DataStatus = 0
GO

索引視圖要求創建的第一個列為唯一聚集索引，所以如下，創建一個唯一的聚集索引

 

　　對於其他索引，可以跟在表上創建索引一樣

　　

 

　

查詢重寫

　　上面說了，查詢重寫就是將基於原始表的查詢語句，直接在索引視圖上查詢實現，那么就來看一下查詢重寫是什么樣子的？
　　下面來觀察這么一個查詢，SQL很明顯地是基於原始表做的查詢，跟普通查詢並無二致，
　　但是觀察執行計划就會發現：
　　這個執行計划走了一個索引查找，首先很清楚，HeadTable上的CreateDate是沒有索引的，這里走的索引就是V_IndexViewTest上的CreatDate列上的索引
　　也就是在索引視圖上創建的第二個索引。

　　

　　如果，查詢語句這么寫，如下，在查詢條件中增加了一個索引視圖中沒有的列，此時查詢就不會被重寫，直接走的是基於原始表的查詢，跟普通查詢並無二致。
　　其實原理不難理解，因為視圖中並不包含HeadInfo這個列，如果在查詢列上加上這個字段，視圖中是沒有這個字段的，那只能基於原始表做查詢了。

　　

 

 

為什么查詢會被重寫

　　上面我們看到了，對於合適的查詢，查詢是會被重寫的，也就是查詢直接基於索引視圖來實現，那么為什么會直接基於視圖來實現呢？
　　還是處於性能上的考慮，因為索引視圖在創建唯一的聚集索引之后，視圖就“固化了”原始表的結果集，
　　此時的視圖與普通視圖最大的區別就是，視圖中直接存儲了數據本身，而非一個查詢，
　　此時的視圖中的數據集，相當於基於原表的一個“子集”，因為是子集，這個結果集必然小於原始表，
　　那么同樣的查詢字段和查詢條件，不但可以減少表與表之間的鏈接操作，且結果集更小，從這個視圖上查詢，
　　同等條件下可以更快地返回結果，所以查詢重寫也就不難理解了。
　　此時只要查詢字段和查詢條件一樣，基於原始表的查詢和直接查詢索引視圖是一樣的，如下截圖

　　

 

 

索引視圖什么時候更新

　　上面說了查詢重寫，如果條件允許，基於原始表的查詢會直接從索引視圖上來實現。
　　可能有人會不放心，畢竟數據都是基於物理表做增刪改的，而索引視圖中的數據又是物理存在的，那就就會有一個擔心，基於視圖的查詢會不會不准確？
　　畢竟是我好好的一個查詢，你默認給我定位到索引視圖上，查詢結果會跟原始表查詢一致嗎?

　　那么就要求證一下，索引視圖中的數據是如何更新的。
　　我們做這么一個測試，在基表，也就是DetailTable中查詢一條數據，看看到底在執行計划中發生了什么
　　可以明顯地看到，不僅僅是王DetailTable中寫入了一條數據，同時，基於索引視圖的查詢也往索引視圖中寫入了一條數據，
　　因此可以放心地使用索引視圖而不必擔心索引視圖中的數據和基表的數據不一致的問題。

　　但是要注意的就是，此時的寫，是寫入基表的同事，也寫入了索引視圖，對寫入的影響是肯定有一些的，如果對寫入效率要求非常高，就要謹慎一點了。
　　其實索引視圖也是一種冗余寫來實現查詢效率的提高的。

 

 

改變基於視圖的查詢

　　上面說了，某些基於視圖的查詢，是直接定位到視圖，從視圖中查詢結果返回的，如下圖

 

但是如果真的不想從視圖中查詢，我就是想對比一下原始表和基於視圖查詢的（效率上的）區別，該怎么辦?
這個也好辦，可以通過查詢提示，將查詢來基於原始表實現，也就是展開這個索引視圖了
OPTION (EXPAND VIEWS)這個查詢提示就是將視圖展開，從原始表進行查詢，默認情況下是不展開的
如截圖，可以強制展開索引視圖，從原始表查詢

 

那么效率對比呢?如下截圖，粗看起來，這個效率差別還是挺大的，可見，SQL Server默認選擇下，載效率上還是有一定的考慮的

 

　　這里從索引視圖查詢，一是減少了表之間的join，而是索引視圖的結果集更小，從中篩選符合條件的數據效率就會更好一些。
　　所以，默認情況下是會從視圖查詢來對SQL進行查詢重寫的。　　

 　  索引視圖的查詢提示：with(noexpand) 強制不展開，OPTION (EXPAND VIEWS)強制展開

總結：

　　本文粗淺地分析了SQL Server 中的索引視圖以及索引視圖帶來的查詢重寫功能，通過索引視圖固化基表的結果集，
　　可以在一定程度上提高查詢效率，尤其是在超級大的多表join的時候，直接將原始結果存為一個索引視圖，
　　通過對索引視圖查詢來減少表之間的join和IO來提高效率,不失為一種優化選擇。
　　需要注意的是，SQL Server的索引視圖限制非常多，具體可以參考鏈接叢書或者MSND，並不是所有的情況都可以使用索引視圖來實現。

 

本人技術水平還很菜，說的不對還請支出，謝謝。