执行计划重编译的时机
參考文獻:
執行計劃的緩存和重新使用
重新編譯執行計劃
根據數據庫新狀態的不同,數據庫中的某些更改可能導致執行計劃效率降低或無效。SQL Server 將檢測到使執行計劃無效的更改,并將計劃標記為無效。此后,必須為執行查詢的下一個連接重新編譯新的計劃。導致計劃無效的情況包括:
為了使語句正確,或要獲得可能更快的查詢執行計劃,大多數都需要進行重新編譯。
在 SQL Server 2000 中,只要批處理中的語句導致重新編譯,就會重新編譯整個批處理,無論此批處理是通過存儲過程、觸發器、即席批查詢,還是通過預定義的語句進行提交。在 SQL Server 2005 中,只有在批處理中導致重新編譯的語句才會被重新編譯。由于這種差異,SQL Server 2000 和 SQL Server 2005 中的重新編譯計數不可比較。另外,由于 SQL Server 2005 擴展了功能集,因此,具有更多重新編譯類型。
語句級重新編譯有助于提高性能,因為在大多數情況下,只有少數語句導致了重新編譯并造成相關損失(指 CPU 時間和鎖)。因此,避免了批處理中其他不必重新編譯的語句的這些損失。
SQL Server Profiler?SP:Recompile?跟蹤事件在 SQL Server 2005 中報告語句級重新編譯。此跟蹤事件在 SQL Server 2000 中僅報告批處理重新編譯。此外,在 SQL Server 2005 中,將填充此事件的?TextData?列。因此,已不再需要 SQL Server 2000 中必須跟蹤?SP:StmtStarting?或SP:StmtCompleted?以獲取導致重新編譯的 Transact-SQL 文本的做法。
SQL Server 2005 也添加了一個新跟蹤事件,稱為?SQL:StmtRecompile,它報告語句級重新編譯。此跟蹤事件可用于跟蹤和調試重新編譯。SP:Recompile?僅針對存儲過程和觸發器生成,而?SQL:StmtRecompile?則針對存儲過程、觸發器、即席批查詢、使用?sp_executesql?執行的批處理、已準備的查詢和動態 SQL 生成。
SP:Recompile?和?SQL:StmtRecompile?的?EventSubClass?列都包含一個整數代碼,用以指明重新編譯的原因。下表包含每個代碼號的意思。
| 1 | 架構已更改。 |
| 2 | 統計信息已更改。 |
| 3 | 編譯已延遲。 |
| 4 | SET 選項已更改。 |
| 5 | 臨時表已更改。 |
| 6 | 遠程行集已更改。 |
| 7 | FOR BROWSE 權限已更改。 |
| 8 | 查詢通知環境已更改。 |
| 9 | 分區視圖已更改。 |
| 10 | 游標選項已更改。 |
| 11 | 已請求 OPTION (RECOMPILE)。 |
注意
當 AUTO_UPDATE_STATISTICS 數據庫選項被設置為 ON 時,如果查詢以表或索引視圖為目標,而表或索引視圖的統計信息自上次執行后已更新或基數已發生很大變化,查詢將被重新編譯。此行為適用于標準用戶定義表、臨時表以及由 DML 觸發器創建的?inserted和?deleted表。如果過多的重新編譯影響到查詢的性能,請考慮將此設置更改為 OFF。當 AUTO_UPDATE_STATISTICS 數據庫選項設置為 OFF 時,不會因統計信息或基數的更改而發生任何重新編譯,但是,由 DML INSTEAD OF 觸發器創建的?inserted和?deleted表除外。因為這些表是在tempdb中創建的,因此,是否重新編譯訪問這些表的查詢取決于?tempdb中 AUTO_UPDATE_STATISTICS 的設置。請注意,在 SQL Server 2000 中,即使此設置為 OFF,查詢仍然會基于 DML 觸發器?inserted和?deleted表的基數變化進行重新編譯。有關禁用 AUTO_UPDATE_STATISTICS 的詳細信息,請參閱索引統計信息。總結
以上是生活随笔為你收集整理的执行计划重编译的时机的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 也谈大公司病1——正确是最大的错误
- 下一篇: 影驰显卡怎么样?