SQL Server 優化---爲何索引視圖（物化視圖）須要with(noexpand)強制查詢提示

原文: SQL Server 優化---爲何索引視圖（物化視圖）須要with(noexpand)強制查詢提示

 

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

 

第一次經過索引視圖優化SQL語句，以及遇到的一些問題，記錄一下。

 

語句分析

最近開發遞交過來一個查詢統計的SQL，說是性能有問題，本來執行須要4-5秒鐘，這個業務自己對性能要求又比較critical，指望是在1s以內
在用盡各類辦法以後（執行計劃，統計信息，索引，改寫SQL，臨時表拆分），依然沒有實質性的改觀，
在觀察SQL自己的特色以後，
有如下幾個特色
　　1，查詢語句總體爲多表join，可是每一個表自身的數據並非很是大，百萬級
　　2，查詢結果在主表上一個較大的時間範圍的數據進行Count的聚合操做
　　3，幾張表之間除了鏈接條件，主要是進行了一些比較複雜的邏輯運算（下面截圖能夠看到，沒多少IO，CPU時間卻很高）
　　　 不過表的鏈接方式都是inner join，主要性能點就在於表關聯之間的Hash join之間的邏輯運算，參考下圖（是執行計劃的一部分）

　　經過統計信息發現，該SQL語句的物理IO並不高,說明索引沒有什麼問題，經過索引改善IO可能改善空間頗有限
　　時間主要花費在SQL語句的編譯和的Hash join 運算
　　嘗試改寫藉助SQL以後（純改寫SQL和藉助臨時表拆分語句），發現依然很難繞過Hash join，主要是表之間的邏輯運算最爲耗時
　　最後想到能夠先將運算好的的數據物理存儲起來，而後改寫查詢的SQL語句完成等價的查詢，
　　避免每次查詢都作複雜的邏輯運算，應該能夠有比較大的改善，因而就想到了索引視圖

　　

建立索引視圖改寫SQL

　　在提取出來原始的查詢SQL，建立索引視圖，並在索引視圖上建立unique cluster index和合理的nocluster index
　　經過索引視圖改寫原始的查詢統計SQL語句，
　　改寫後的SQL語句是一個索引視圖替代原始的4張表，與另一個物理表join，發現效率上沒有任何改善，
　　觀察改寫後的SQL語句的執行計劃，發現跟原始SQL同樣，並無走索引視圖上的索引，或者說是用到索引視圖，一時間以爲好心塞，實在沒招了
　　執行計劃依舊是長長的一大段，而後依舊是好幾個Hash Join.參考下圖，執行計劃跟本文第一個截圖如出一轍

　　按道理，索引視圖固化結果集，而且根據狀況作了過濾，結果集是原始查詢的一部分而已，
　　用一樣的查詢條件從索引視圖作查詢統計，走索引視圖代價確定要比原始SQL低，經過強制不展開with(noexpand)提示，證明了這個推斷
　　以下是強制不展開索引視圖的統計信息，能夠看到徹底達到了預期的1S以內

　　

 

　　固然索引視圖也不是沒有代價，在必定程度上犧牲了數據寫入的效率和冗餘存儲，來換取查詢的效率
　　以前簡單介紹過索引視圖的一些特色 http://www.cnblogs.com/wy123/p/6041122.html

 

索引視圖被展開(expand)的緣由分析

　　最關鍵的問題在於，沒有強制不展開索引視圖（with(noexpand)提示）的狀況下，爲何沒有走索引視圖呢？

　　這個問題確實鬱悶了一陣子，整個半天都在想這個問題，由於索引視圖自己用的就少，出現此問題更是一頭霧水，不過Google一下，還有一大把相似的問題
　　以下是在google的時候查到的，原文是英文，大概意思以下，非直譯。

　　參考連接：http://dba.stackexchange.com/questions/26979/what-factors-go-into-an-indexed-views-clustered-index-being-selected/27039#27039

索引視圖的匹配（查詢用索引視圖替代而不走原始的基礎表）是一個至關昂貴的操做，所以優化器試圖經過其餘方式快速轉換（生成執行計劃）
若是優化器產生了一個相對優化的執行計劃，就能夠儘早結束（沒必要繼續生成其餘執行計劃）
問題就在於：繼續生成其餘執行計劃的代價要大於已生成的執行計劃的代價
聽起來有點彆扭，
以前舉過這麼一個例子，好比說是花3秒鐘找到一個相對優化的執行計劃，這個執行計劃完成SQL的執行須要2秒鐘
與花10秒鐘的時候找到一個最優化的執行計劃，儘管這個執行計劃完成SQL的執行可能只須要0.5秒鐘，雖而後者的執行計劃更優，但總體代價更大
優化器的主要目標是儘快找到一個足夠好的執行計劃（而非老是生成最好的執行計劃）

使用索引視圖自己並非一個昂貴的操做，
可是與潛在索引視圖中匹配邏輯查詢樹確實一個代價較大的行爲，在查詢涉及的視圖在優化器優化以前已經被展開
所以優化器並不知道你的查詢是否未被了索引視圖，他看到的只是展開的查詢樹
這個通俗地講就是：
讓sqlserver知道，一個查詢，能夠用索引視圖中的結果等價替代視圖邏輯中原始的基表，是一個代價較大的過程
由於SQL Server根據原始的基礎表，生成一種執行計劃以後，就不去判斷是否能夠用索引視圖作等價替代。

 　　固然白皮書裏有更詳細的介紹，裏面索引視圖相關的一些邏輯實現和分析http://www.cs.cmu.edu/~natassa/courses/15-823/current/papers/vldb00.pdf

 

最後多逼逼一句：
　　上面的白皮書實在看不懂，只是Google出來講詳細信息請看這個參考資料,
　　這裏只是從現象去推斷優化器在面對索引視圖的一些特性，瞭解到內在機制的一些特色，可能潛在的問題，以及對應的解決辦法
　　這裏又提開源軟件了，別說不開源了，即使是開源了，除了錢的因素，在技術上，有幾我的能夠動一下這些大型軟件的核心代碼？
　　我並非在黑開源軟件啊，只是聽有人說，開源好啊，有源碼怎麼怎麼樣，以爲夠裝13的，
　　國內除了bat等少數幾家公司作過修改源碼，作過開源數據庫的定製，試問還有多少家能夠修改數據庫源碼而後上生產使用

　　最近在學MySQL，繼續SQL Server下去恐怕踏馬要失業了，開源，對大多數公司來講，錢纔是一個大頭因素吧，尼瑪跑題了。