SQL Server執行計畫

標籤：尋找   返回   cache   響應   free   臨時   分析   ccache   無法   

SQL Server 針對使用者提交的DML語句，通過一系列的最佳化後，產生出一個能被SQL Server識別並高效“響應”的方案，用Ctrl+M（實際執行計畫）在用Ctrl+L（預估執行計畫）

提交一個DML語句（CRUD）會引起一系列的活動。

1.發生在關聯式引擎中的活動

2.發生在儲存引擎中的活動

在關聯式引擎中，查詢被解析後傳給查詢最佳化工具；在查詢最佳化工具中，查詢被分析計算後產生執行計畫，然後發給儲存引擎，儲存引擎按照計劃尋找或修改資料，之後返回給用戶端

需要注意的是最佳化器產生的預估執行計畫，而在儲存引擎中產生的才是實際執行計畫。這個計劃可能與預估執行計畫有出入，一下原因會導致二者有出入。

1.由於超過了並存執行的閾值，導致原有計劃更改，使用了並存執行，

2.統計資訊變更、過時、這時候也會更改預估執行計畫

3.由於某些情況產生了重編譯

二：預估與實際執行計畫

1.執行計畫有兩類：一類是預估執行計畫，由最佳化器產生，標識執行的邏輯步驟；另一類是實際執行計畫，在實際執行計畫中產生，標識實際執行的情況。

大部分情況下實際執行計畫和預估執行計畫是相同的，預估執行計畫是存放在計畫快取中的，可以通過訪問這些緩衝中的計劃得出統計資料。特別是對於一些大查詢來說，擷取實際執行計畫往往不現實。實際執行計畫可用於擷取實際行數、實際統計資訊。

2.執行計畫重用

通過重用已經存在的計畫快取中的執行計畫。可以大大降低伺服器的開銷。

在提交查詢後，在Algebrizer階段會建立一個hash資料用於唯一標識這個查詢，並且會標識查詢的語句，最佳化器會對比這個hash和緩衝中hash，如果查詢已經存在，它就會跳過最佳化並重用緩衝中的執行計畫。

為了重用執行計畫，在編碼時，儘可能編寫一些SQL Server 重用的代碼，參數化查詢就是其中的一種，預存程序也是一個不錯的選擇，如果用硬式編碼方式編寫語句，即使少量的修改都會引起緩衝丟失，因為指令碼已經不同，SQL Server 無法找到緩衝的hash值，會引起不必要的最佳化開銷。

SQLServer 不會永久儲存計劃的緩衝，並且存在緩衝中的計劃也不會永久不變，每個計劃都會有一個age值，當Algebrizer觸發時，會掃描這個age值，並且每次降低這個值。

在滿足下面全部的條件時，預估執行計畫會被移除出記憶體。

1.作業系統需要更多的記憶體

2.Age值已經降低到0

3.執行計畫沒有被當前的串連使用

導致執行計畫重新編譯，得避免下面的情景。

1.查詢所引用的表結構或者架構更改

2.查詢所用的索引更改

3.查詢用到的索引被刪除

4.顯示調用sp_recompile

5.查詢引用的表上，由於在索引值上有大量的Insert/Delete操作，引起了統計資訊的更改

6.單一查詢中混合了DDL和DML操作，稱為延遲編譯

7.在查詢中修改了SET選項

8.查詢所用到的暫存資料表的架構、結構修改

9.查詢過程中遊標選項更改

三：清除緩衝中的執行計畫

DBCC  FREEPROCCACHE

四：執行計畫格式

SQL Server執行計畫