優(yōu)化SQL語句中的物理查詢方法分享

申請免費試用、咨詢電話：400-8352-114

from tab1, tab2

where tab1.id = tab2.id and tab1.col1 = 123 and tab2.col1 = 'abc'

照你所述的執(zhí)行順序，先要tab1和tab2進行笛卡爾乘積，再按照tab1.col1 = 123 and tab2.col1 = 'abc‘進行篩選。這樣的話，效率豈不是很低，數(shù)據(jù)庫有這么愚蠢嗎？

我想很多人都會有這個疑問，包括我在最初學習的時候也提出過這樣的問題。那么，我的這篇文章就結合這個問題來討論一下SQL Server的物理查詢處理。首先我們必須明白邏輯處理和物理處理和區(qū)別，邏輯處理是指執(zhí)行一個查詢應該產(chǎn)生什么樣的結果，那么邏輯查詢的各個階段就是這個查詢從邏輯上執(zhí)行的先后順序，依照這個先后順序就能得到正確的結果，正如我們做四則混合運算一樣，先乘除后加減才能得到正確結果。

所以說邏輯查詢只關心產(chǎn)生一個我們期望的、正確的結果，它并不關心產(chǎn)生這個結果需要多少的資源消耗。而物理處理就是怎么得到這個結果，這個時候才會考慮性能問題。下面我們就討論下怎么執(zhí)行這個物理處理的。

當一個查詢到達數(shù)據(jù)庫引擎的時候，數(shù)據(jù)庫引擎需要做的是執(zhí)行這個查詢的查詢計劃，那么這個時候就存在兩種情況，一種可能是這個查詢的查詢計劃已經(jīng)在緩存中，這種情況就直接執(zhí)行這個查詢計劃。另外一種情況就是在緩存中找不到該查詢的查詢計劃。沒有怎么辦？生成一個！怎么生成？

執(zhí)行計劃是在編譯階段生成的，編譯需要經(jīng)過三個步驟：分析、代數(shù)化（algebrization）、查詢優(yōu)化，看見沒有這里的查詢優(yōu)化過程就能解決上面的朋友提出的先笛卡爾集在篩選造成性能低的問題。下面我就對這三個步驟作一個介紹。

第一步：分析是檢查語法并把SQL批處理轉(zhuǎn)化成分析樹的過程，如select * t1 where id in（1,2,3,4,5,6,7）在被分析樹分析后就展開成了select * t1 where id=1 or id=2 or id=3 or id=4 or id=5 or id=6 or id=7 ,除此之外還有檢查語法是否正確的功能。

第二步：接下的過程是代數(shù)化（algebrization），這個階段使用SQL Server 2005的新組件algebrizer，algebrizer組件的主要功能是綁定，因此代數(shù)化過程通常稱為綁定。這個階段是將第一步的分析樹作為輸入，生成被稱為查詢處理器樹的輸出，用于查詢優(yōu)化。其實這個階段主要做幾個事情，

一：運算符平展，簡單的講就是把二元運算符組合成N元運算符，這里必須給出一個示例才能很好的解釋這個二元轉(zhuǎn)換成N元如第一步所示in操作展開成了一連串的or運算符，而分析器認為這些or都是二元的，也就是說它認為第一個or 的左孩子是id=1,右孩子是 （id=2 or id=3 or id=4 or id=5 or id=6 or id=7 ）這個表達式，而右孩子又被認為是二元的，如此一來就必須進行一個遞歸過程。而運算符平展過程則將這種二元運算組合成n元運算符，就避免了遞歸的過程。

二：名稱解析，這個過程其實就是檢查這個查詢中出現(xiàn)的表或者是表的列是不是在數(shù)據(jù)庫中真實存在。以及在該查詢過程中是不是可見的。三：類型派生，有點抽象，舉個例子就能理解了，比如union查詢吧，union左右兩邊查詢結果對應位置的數(shù)據(jù)類型應該是一致的。四：聚合綁定和組分綁定，執(zhí)行完這個步驟后查詢處理器樹便生成了。

第三步：查詢優(yōu)化，這個過程由查詢優(yōu)化器組件來完成的。查詢中應該以何種順序訪問表，使用哪種方法和使用哪個索引，應該由哪個聯(lián)接算法等都是由查詢優(yōu)化器組件來決定的，但是這個決定也不是隨意的，它必須滿足的前提條件是保證最后得到的結果集必須是正確的，也就是說該結果集必須遵循邏輯處理的各個階段所得到的結果集相同。優(yōu)化器會嘗試該查詢的許多變體，一查找成本最低的計劃。

如果優(yōu)化器分析該查詢的元數(shù)據(jù)得知只有一個可執(zhí)行的計劃，那么它就不會再嘗試尋求更好的計劃，這個步驟叫做細微計劃優(yōu)化。如果沒有找到細微計劃優(yōu)化，SQL Server將執(zhí)行一些簡化，簡化就是對自身語法作一些轉(zhuǎn)換，比如在聯(lián)接前計算表的where篩選器，如前一篇描述的，邏輯查詢中where篩選總是在聯(lián)接之后計算，但是先計算where篩選器在聯(lián)接同樣能得到的正確的結果，而這樣的效率往往是更高的，所以在物理處理中where往往在join前執(zhí)行的，開篇提到的那個問題只是讀者未理解邏輯處理和物理處理的差別而已。

到此為止，物理處理的各個步驟也做了一個簡要的敘述，總結下，無論是存儲過程還是即席查詢都是執(zhí)行的一個查詢計劃的副本，如果這個查詢計劃不存在的話就必須經(jīng)過編譯生成一個執(zhí)行計劃，在編譯階段必須經(jīng)過分析，綁定（代數(shù)化），查詢優(yōu)化這些過程，最終得到我們需要查找的結果。關于查詢優(yōu)化組件具體是怎么優(yōu)化查詢處理器樹的，我會在以后的篇幅作詳細介紹。（51CTO）