我并非專業(yè)DBA,但做為B/S架構(gòu)的開發(fā)人員,總是離不開數(shù)據(jù)庫,一般開發(fā)員只會應(yīng)用SQL的四條經(jīng)典語句:select ,insert,delete,update。但是我從來沒有研究過它們的工作原理,這篇我想說一說select在數(shù)據(jù)庫中的工作原理。B/S架構(gòu)中最經(jīng)典的話題無非于三層架構(gòu),可以大概分為數(shù)據(jù)層,業(yè)務(wù)邏輯層和表示層,而數(shù)據(jù)層的作用一般都是和數(shù)據(jù)庫交互,例如查詢記錄。
我們經(jīng)常是寫好查詢SQL,然后調(diào)用程序執(zhí)行SQL。但是它內(nèi)部的工作流程是怎樣的呢？先做哪一步，然后做哪一步等,我想還有大部分朋友和我一樣都不一定清楚。
第一步：應(yīng)用程序把查詢SQL語句發(fā)給服務(wù)器端執(zhí)行。
我們在數(shù)據(jù)層執(zhí)行SQL語句時,應(yīng)用程序會連接到相應(yīng)的數(shù)據(jù)庫服務(wù)器,把SQL語句發(fā)送給服務(wù)器處理。
第二步：服務(wù)器解析請求的SQL語句。
1:SQL計劃緩存,經(jīng)常用查詢分析器的朋友大概都知道這樣一個事實(shí),往往一個查詢語句在第一次運(yùn)行的時候需要執(zhí)行特別長的時間,但是如果你馬上或者在一定時間內(nèi)運(yùn)行同樣的語句,會在很短的時間內(nèi)返回查詢結(jié)果。
原因:
1):服務(wù)器在接收到查詢請求后,并不會馬上去數(shù)據(jù)庫查詢,而是在數(shù)據(jù)庫中的計劃緩存中找是否有相對應(yīng)的執(zhí)行計劃,如果存在,就直接調(diào)用已經(jīng)編譯好的執(zhí)行計劃,節(jié)省了執(zhí)行計劃的編譯時間。
2):如果所查詢的行已經(jīng)存在于
數(shù)據(jù)緩沖存儲區(qū)中,就不用查詢物理文件了,而是從緩存中取數(shù)據(jù),這樣從內(nèi)存中取數(shù)據(jù)就會比從硬盤上讀取數(shù)據(jù)快很多,提高了查詢效率.數(shù)據(jù)緩沖存儲區(qū)會在后面提到。
2:如果在SQL計劃緩存中沒有對應(yīng)的執(zhí)行計劃,服務(wù)器首先會對用戶請求的SQL語句進(jìn)行
語法效驗(yàn),如果有語法錯誤,服務(wù)器會結(jié)束查詢操作,并用返回相應(yīng)的錯誤信息給調(diào)用它的應(yīng)用程序。
注意:此時返回的錯誤信息中,只會包含基本的語法錯誤信息,例如select 寫成selec等,錯誤信息中如果包含一列表中本沒有的列,此時服務(wù)器是不會檢查出來的,因?yàn)橹皇钦Z法驗(yàn)證,語義是否正確放在下一步進(jìn)行。
3:語法符合后,就開始驗(yàn)證它的
語義是否正確,例如,表名,列名,存儲過程等等數(shù)據(jù)庫對象是否真正存在,如果發(fā)現(xiàn)有不存在的,就會報錯給應(yīng)用程序,同時結(jié)束查詢。
4:接下來就是
獲得對象的解析鎖,我們在查詢一個表時,首先服務(wù)器會對這個對象加鎖,這是為了保證數(shù)據(jù)的統(tǒng)一性,如果不加鎖,此時有數(shù)據(jù)插入,但因?yàn)闆]有加鎖的原因,查詢已經(jīng)將這條記錄讀入,而有的插入會因?yàn)槭聞?wù)的失敗會回滾,就會形成臟讀的現(xiàn)象。
5:接下來就是對
數(shù)據(jù)庫用戶權(quán)限的驗(yàn)證,SQL語句語法,語義都正確,此時并不一定能夠得到查詢結(jié)果,如果數(shù)據(jù)庫用戶沒有相應(yīng)的訪問權(quán)限,服務(wù)器會報出權(quán)限不足的錯誤給應(yīng)用程序,在稍大的項(xiàng)目中,往往一個項(xiàng)目里面會包含好幾個數(shù)據(jù)庫連接串,這些數(shù)據(jù)庫用戶具有不同的權(quán)限,有的是只讀權(quán)限,有的是只寫權(quán)限,有的是可讀可寫,根據(jù)不同的操作選取不同的用戶來執(zhí)行,稍微不注意,無論你的SQL語句寫的多么完善,完美無缺都沒用。
6:解析的最后一步,就是
確定最終的執(zhí)行計劃。當(dāng)語法,語義,權(quán)限都驗(yàn)證后,服務(wù)器并不會馬上給你返回結(jié)果,而是會針對你的SQL進(jìn)行優(yōu)化,選擇不同的查詢算法以最高效的形式返回給應(yīng)用程序。例如在做表聯(lián)合查詢時,服務(wù)器會根據(jù)開銷成本來最終決定采用hash join,merge join ,還是loop join,采用哪一個索引會更高效等等,不過它的自動化優(yōu)化是有限的,要想寫出高效的查詢SQL還是要優(yōu)化自己的SQL查詢語句。
當(dāng)確定好執(zhí)行計劃后,就會把這個執(zhí)行計劃保存到SQL計劃緩存中,下次在有相同的執(zhí)行請求時,就直接從計劃緩存中取,避免重新編譯執(zhí)行計劃。
第三步：語句執(zhí)行。
服務(wù)器對SQL語句解析完成后,服務(wù)器才會知道這條語句到底表態(tài)了什么意思,接下來才會真正的執(zhí)行SQL語句。
些時分兩種情況:
1):如果查詢語句所包含的數(shù)據(jù)行已經(jīng)讀取到
數(shù)據(jù)緩沖存儲區(qū)的話,服務(wù)器會直接從數(shù)據(jù)緩沖存儲區(qū)中讀取數(shù)據(jù)返回給應(yīng)用程序,避免了從物理文件中讀取,提高查詢速度。
2):如果數(shù)據(jù)行沒有在數(shù)據(jù)緩沖存儲區(qū)中,則會從物理文件中讀取記錄返回給應(yīng)用程序,同時把數(shù)據(jù)行寫入數(shù)據(jù)緩沖存儲區(qū)中,供下次使用。
說明:SQL緩存分好幾種,這里有興趣的朋友可以去搜索一下,有時因?yàn)榫彺娴拇嬖?使得我們很難馬上看出優(yōu)化的結(jié)果,因?yàn)榈诙螆?zhí)行因?yàn)橛芯彺娴拇嬖?會特別快速,所以一般都是先消除緩存,然后比較優(yōu)化前后的性能表現(xiàn),這里有幾個常用的方法:
DBCC DROPCLEANBUFFERS
從緩沖池中刪除所有清除緩沖區(qū)。
DBCC FREEPROCCACHE
從過程緩存中刪除所有元素。
DBCC FREESYSTEMCACHE
從所有緩存中釋放所有未使用的緩存條目。SQL Server 2005 數(shù)據(jù)庫引擎會事先在后臺清理未使用的緩存條目，以使內(nèi)存可用于當(dāng)前條目。但是，可以使用此命令從所有緩存中手動刪除未使用的條目。
這只能基本消除SQL緩存的影響,目前好像沒有完全消除緩存的方案,如果大家有,請指教。
結(jié)論:只有知道了服務(wù)執(zhí)行應(yīng)用程序提交的SQL的操作流程才能很好的調(diào)試我們的應(yīng)用程序。
1:確保SQL語法正確;
2:確保SQL語義上的正確性,即對象是否存在;
3:數(shù)據(jù)庫用戶是否具有相應(yīng)的訪問權(quán)限。