SQLpassion Performance Tuning Training Plan
我的學習翻譯,若有謬誤,請不吝指出,感謝.
Week 1: SQL Server如何執行一個查詢
在咱們進入SQL Server性能調優的繁雜細節以前, 我想先列舉一下SQL Server如何執行一個查詢(query)的結構,
這部份內容很是重要, 由於瞭解這些概念, 對咱們之後的性能調優課程會理解的更加深入.
下面的圖爲咱們展現了SQL Server執行查詢過程當中所包含的幾個主要組成部分:
SQL Server內部能夠分離成兩個部分:
Relational Engine 和
Storage Engine. 其中在
relational engine 中最大的組件是
Query Optimizer .
它惟一的任務就是把咱們傳給SQL Server的查詢產生一個物理執行計劃(
physical execution plan)
讀取數據
首先,咱們提交給SQL Server的查詢經由
Protocol Layer(協議層)傳給
Command Parser(命令解析器), 後者檢查語法是否合法, 引用的表、列等對象是否正確.
Command Parser最後產生的結果就是所謂的
Query Tree, 它描述了咱們的查詢結構, 爲後續的Query Optimizer所用,從而產生執行計劃.
編譯好的執行計劃隨後交由
Query Executor執行, 但在執行以前,執行計劃會先被
Plan Cache緩存起來, 以做複用(Plan Cache是一個很是有用同時也很是危險的概念,後面在week10咱們會談到這些).
在執行計劃被緩存後, Query Executor開始和Storage Engine交互,執行每個操做.
當咱們的查詢須要訪問數據(大部分都是select)時,
Access Methods會先向
Buffer Manager詢問是否有咱們想要讀取的指定數據頁(下一節咱們來說數據頁: Pages, 如今你只要知道pages就是一個8kb的存儲區間),
Buffer Manager管理着
Buffer Pool, 後者保存着不少數據頁, 它是SQL Server中主要的內存消耗者, 咱們能夠在配置中設定它的大小Size.
若是被請求的頁已經存儲在Buffer Pool中, 則能夠當即被返回. 這稱之爲邏輯讀(Logical Read). 若是被請求的頁不存在於Buffer Pool中, 則Buffer Manager會異步發起一個IO操做, 將被請求頁從存儲系統中讀進Buffer Pool中,這稱之爲物理讀(Physical Read).
整個查詢必須等待物理讀的異步操做完成才能夠,咱們在week22,再討論等待的一些細節.
一旦全部的請求頁都讀進了Buffer Pool,就會返回給Access Methods,而後執行計劃完成後,處理完的數據就會經由protocal layer返回給應用程序.整個查詢到此完成.
修改數據
當咱們運行一些insert,update,delete等會修改數據的命令時, Storage Engine會額外用到
Transaction Manager. 它的做用是寫一條日誌記錄到Transaction log中, 以描述咱們的操做產生了哪些變化. 這條日誌記錄會迅速的硬化, 並提交. 這意味着咱們的SQL Server實例會盡量快的處理事務日誌. 頁首先在內存中被改寫,而後再寫入到磁盤上, 這中間的過程咱們稱之爲
Check Point, 它每時每刻都在運行, 不斷的向Buffer Manager請求髒頁(dirty pages). 髒頁即已在內存中產生了變化,但未及時寫入到磁盤中的頁. 一旦髒頁寫入到磁盤,就會被標記爲乾淨頁.
總結
如你所見, 當咱們執行一個簡單的查詢時, SQL Server內部發生了許多的事情,不一樣的角色承擔了不一樣的功能, 在調優過程當中, 咱們不得不該對每一個角色都有可能產生的一系列性能問題.