作為Web開發(fā)人員，雖并非專業(yè)的DBA，但我們總是離不開數(shù)據庫。一般開發(fā)員只會應用SQL的四條經典語句:select，insert，delete，update。以至于從來沒有研究過它們的工作原理，在這里我們說一說select在數(shù)據庫中的工作原理。

B/S架構中最經典的話題無非于三層架構，可以大概分為數(shù)據層，業(yè)務邏輯層和表示層，而數(shù)據層的作用一般都是和數(shù)據庫交互，例如查詢記錄。我們經常是寫好查詢SQL，然后調用程序執(zhí)行SQL。但是它內部的工作流程是怎樣的呢？先做哪一步，然后做哪一步等，我想還有大部分朋友和我一樣都不一定清楚。

第一步：應用程序把查詢SQL語句發(fā)給服務器端執(zhí)行

我們在數(shù)據層執(zhí)行SQL語句時，應用程序會連接到相應的數(shù)據庫服務器，把SQL語句發(fā)送給服務器處理。

第二步：服務器解析請求的SQL語句

1.SQL計劃緩存，經常用查詢分析器的朋友大概都知道這樣一個事實，往往一個查詢語句在第一次運行的時候需要執(zhí)行特別長的時間，但是如果你馬上或者在一定時間內運行同樣的語句，會在很短的時間內返回查詢結果。

原因：

• 服務器在接收到查詢請求后，并不會馬上去數(shù)據庫查詢，而是在數(shù)據庫中的計劃緩存中找是否有相對應的執(zhí)行計劃，如果存在，就直接調用已經編譯好的執(zhí)行計劃，節(jié)省了執(zhí)行計劃的編譯時間。
• 如果所查詢的行已經存在于數(shù)據緩沖存儲區(qū)中，就不用查詢物理文件了，而是從緩存中取數(shù)據，這樣從內存中取數(shù)據就會比從硬盤上讀取數(shù)據快很多，提高了查詢效率.數(shù)據緩沖存儲區(qū)會在后面提到。

2.如果在SQL計劃緩存中沒有對應的執(zhí)行計劃，服務器首先會對用戶請求的SQL語句進行語法效驗，如果有語法錯誤，服務器會結束查詢操作，并用返回相應的錯誤信息給調用它的應用程序。

注意:此時返回的錯誤信息中，只會包含基本的語法錯誤信息，例如select寫成selec等，錯誤信息中如果包含一列表中本沒有的列，此時服務器是不會檢查出來的，因為只是語法驗證，語義是否正確放在下一步進行。

3.語法符合后，就開始驗證它的語義是否正確，例如，表名，列名，存儲過程等等數(shù)據庫對象是否真正存在，如果發(fā)現(xiàn)有不存在的，就會報錯給應用程序，同時結束查詢。

4.接下來就是獲得對象的解析鎖，我們在查詢一個表時，首先服務器會對這個對象加鎖，這是為了保證數(shù)據的統(tǒng)一性，如果不加鎖，此時有數(shù)據插入，但因為沒有加鎖的原因，查詢已經將這條記錄讀入，而有的插入會因為事務的失敗會回滾，就會形成臟讀的現(xiàn)象。

5.接下來就是對數(shù)據庫用戶權限的驗證，SQL語句語法，語義都正確，此時并不一定能夠得到查詢結果，如果數(shù)據庫用戶沒有相應的訪問權限，服務器會報出權限不足的錯誤給應用程序，在稍大的項目中，往往一個項目里面會包含好幾個數(shù)據庫連接串，這些數(shù)據庫用戶具有不同的權限，有的是只讀權限，有的是只寫權限，有的是可讀可寫，根據不同的操作選取不同的用戶來執(zhí)行，稍微不注意，無論你的SQL語句寫的多么完善，完美無缺都沒用。

6.解析的最后一步，就是確定最終的執(zhí)行計劃。當語法，語義，權限都驗證后，服務器并不會馬上給你返回結果，而是會針對你的SQL進行優(yōu)化，選擇不同的查詢算法以最高效的形式返回給應用程序。例如在做表聯(lián)合查詢時，服務器會根據開銷成本來最終決定采用hashjoin，mergejoin，還是loopjoin，采用哪一個索引會更高效等等，不過它的自動化優(yōu)化是有限的，要想寫出高效的查詢SQL還是要優(yōu)化自己的SQL查詢語句。

當確定好執(zhí)行計劃后，就會把這個執(zhí)行計劃保存到SQL計劃緩存中，下次在有相同的執(zhí)行請求時，就直接從計劃緩存中取，避免重新編譯執(zhí)行計劃。

第三步：語句執(zhí)行

服務器對SQL語句解析完成后，服務器才會知道這條語句到底代表了什么意思，接下來才會真正的執(zhí)行SQL語句。

這時分兩種情況:

• 如果查詢語句所包含的數(shù)據行已經讀取到數(shù)據緩沖存儲區(qū)的話，服務器會直接從數(shù)據緩沖存儲區(qū)中讀取數(shù)據返回給應用程序，避免了從物理文件中讀取，提高查詢速度。
• 如果數(shù)據行沒有在數(shù)據緩沖存儲區(qū)中，則會從物理文件中讀取記錄返回給應用程序，同時把數(shù)據行寫入數(shù)據緩沖存儲區(qū)中，供下次使用。

說明:SQL緩存分好幾種，這里有興趣的朋友可以去搜索一下，有時因為緩存的存在，使得我們很難馬上看出優(yōu)化的結果，因為第二次執(zhí)行因為有緩存的存在，會特別快速，所以一般都是先消除緩存，然后比較優(yōu)化前后的性能表現(xiàn)，這里有幾個常用的方法:

DBCC DROPCLEANBUFFERS

從緩沖池中刪除所有清除緩沖區(qū)。

DBCC FREEPROCCACHE

從過程緩存中刪除所有元素。

DBCC FREESYSTEMCACHE

從所有緩存中釋放所有未使用的緩存條目。

SQLServer2005數(shù)據庫引擎會事先在后臺清理未使用的緩存條目，以使內存可用于當前條目。但是，可以使用此命令從所有緩存中手動刪除未使用的條目。

這只能基本消除SQL緩存的影響，目前好像沒有完全消除緩存的方案，如果大家有，請指教。

結論:只有知道了服務執(zhí)行應用程序提交的SQL的操作流程才能很好的調試我們的應用程序。

• 確保SQL語法正確;
• 確保SQL語義上的正確性，即對象是否存在;
• 數(shù)據庫用戶是否具有相應的訪問權限。

總結

以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對本站的支持。如果你想了解更多相關內容請查看下面相關鏈接

香港服務器租用

版權聲明：本站文章來源標注為YINGSOO的內容版權均為本站所有，歡迎引用、轉載，請保持原文完整并注明來源及原文鏈接。禁止復制或仿造本網站，禁止在非maisonbaluchon.cn所屬的服務器上建立鏡像，否則將依法追究法律責任。本站部分內容來源于網友推薦、互聯(lián)網收集整理而來，僅供學習參考，不代表本站立場，如有內容涉嫌侵權，請聯(lián)系alex-e#qq.com處理。