您好,登錄后才能下訂單哦!
小編給大家分享一下數據庫SQL SELECT查詢的示例分析,相信大部分人都還不怎么了解,因此分享這篇文章給大家參考一下,希望大家閱讀完這篇文章后大有收獲,下面讓我們一起去了解一下吧!
作為Web開發人員,雖并非專業的DBA,但我們總是離不開數據庫。一般開發員只會應用SQL的四條經典語句:select,insert,delete,update。以至于從來沒有研究過它們的工作原理,在這里我們說一說select在數據庫中的工作原理。
B/S架構中最經典的話題無非于三層架構,可以大概分為數據層,業務邏輯層和表示層,而數據層的作用一般都是和數據庫交互,例如查詢記錄。我們經常是寫好查詢SQL,然后調用程序執行SQL。但是它內部的工作流程是怎樣的呢?先做哪一步,然后做哪一步等,我想還有大部分朋友和我一樣都不一定清楚。
第一步:應用程序把查詢SQL語句發給服務器端執行
我們在數據層執行SQL語句時,應用程序會連接到相應的數據庫服務器,把SQL語句發送給服務器處理。
第二步:服務器解析請求的SQL語句
1.SQL計劃緩存,經常用查詢分析器的朋友大概都知道這樣一個事實,往往一個查詢語句在第一次運行的時候需要執行特別長的時間,但是如果你馬上或者在一定時間內運行同樣的語句,會在很短的時間內返回查詢結果。
原因:
服務器在接收到查詢請求后,并不會馬上去數據庫查詢,而是在數據庫中的計劃緩存中找是否有相對應的執行計劃,如果存在,就直接調用已經編譯好的執行計劃,節省了執行計劃的編譯時間。
如果所查詢的行已經存在于數據緩沖存儲區中,就不用查詢物理文件了,而是從緩存中取數據,這樣從內存中取數據就會比從硬盤上讀取數據快很多,提高了查詢效率.數據緩沖存儲區會在后面提到。
2.如果在SQL計劃緩存中沒有對應的執行計劃,服務器首先會對用戶請求的SQL語句進行語法效驗,如果有語法錯誤,服務器會結束查詢操作,并用返回相應的錯誤信息給調用它的應用程序。
注意:此時返回的錯誤信息中,只會包含基本的語法錯誤信息,例如select寫成selec等,錯誤信息中如果包含一列表中本沒有的列,此時服務器是不會檢查出來的,因為只是語法驗證,語義是否正確放在下一步進行。
3.語法符合后,就開始驗證它的語義是否正確,例如,表名,列名,存儲過程等等數據庫對象是否真正存在,如果發現有不存在的,就會報錯給應用程序,同時結束查詢。
4.接下來就是獲得對象的解析鎖,我們在查詢一個表時,首先服務器會對這個對象加鎖,這是為了保證數據的統一性,如果不加鎖,此時有數據插入,但因為沒有加鎖的原因,查詢已經將這條記錄讀入,而有的插入會因為事務的失敗會回滾,就會形成臟讀的現象。
5.接下來就是對數據庫用戶權限的驗證,SQL語句語法,語義都正確,此時并不一定能夠得到查詢結果,如果數據庫用戶沒有相應的訪問權限,服務器會報出權限不足的錯誤給應用程序,在稍大的項目中,往往一個項目里面會包含好幾個數據庫連接串,這些數據庫用戶具有不同的權限,有的是只讀權限,有的是只寫權限,有的是可讀可寫,根據不同的操作選取不同的用戶來執行,稍微不注意,無論你的SQL語句寫的多么完善,完美無缺都沒用。
6.解析的最后一步,就是確定最終的執行計劃。當語法,語義,權限都驗證后,服務器并不會馬上給你返回結果,而是會針對你的SQL進行優化,選擇不同的查詢算法以最高效的形式返回給應用程序。例如在做表聯合查詢時,服務器會根據開銷成本來最終決定采用hashjoin,mergejoin,還是loopjoin,采用哪一個索引會更高效等等,不過它的自動化優化是有限的,要想寫出高效的查詢SQL還是要優化自己的SQL查詢語句。
當確定好執行計劃后,就會把這個執行計劃保存到SQL計劃緩存中,下次在有相同的執行請求時,就直接從計劃緩存中取,避免重新編譯執行計劃。
第三步:語句執行
服務器對SQL語句解析完成后,服務器才會知道這條語句到底代表了什么意思,接下來才會真正的執行SQL語句。
這時分兩種情況:
如果查詢語句所包含的數據行已經讀取到數據緩沖存儲區的話,服務器會直接從數據緩沖存儲區中讀取數據返回給應用程序,避免了從物理文件中讀取,提高查詢速度。
如果數據行沒有在數據緩沖存儲區中,則會從物理文件中讀取記錄返回給應用程序,同時把數據行寫入數據緩沖存儲區中,供下次使用。
說明:SQL緩存分好幾種,這里有興趣的朋友可以去搜索一下,有時因為緩存的存在,使得我們很難馬上看出優化的結果,因為第二次執行因為有緩存的存在,會特別快速,所以一般都是先消除緩存,然后比較優化前后的性能表現,這里有幾個常用的方法:
DBCC DROPCLEANBUFFERS
從緩沖池中刪除所有清除緩沖區。
DBCC FREEPROCCACHE
從過程緩存中刪除所有元素。
DBCC FREESYSTEMCACHE
從所有緩存中釋放所有未使用的緩存條目。
SQLServer2005數據庫引擎會事先在后臺清理未使用的緩存條目,以使內存可用于當前條目。但是,可以使用此命令從所有緩存中手動刪除未使用的條目。
這只能基本消除SQL緩存的影響,目前好像沒有完全消除緩存的方案,如果大家有,請指教。
結論:只有知道了服務執行應用程序提交的SQL的操作流程才能很好的調試我們的應用程序。
確保SQL語法正確;
確保SQL語義上的正確性,即對象是否存在;
數據庫用戶是否具有相應的訪問權限。
以上是“數據庫SQL SELECT查詢的示例分析”這篇文章的所有內容,感謝各位的閱讀!相信大家都有了一定的了解,希望分享的內容對大家有所幫助,如果還想學習更多知識,歡迎關注億速云行業資訊頻道!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。