SQL SERVER 優化思路之 SQL查詢語句的執行順序

要優化SQL 首先咱們得了解SQL的執行順序：

例子：查詢語句中select from where group by having order by的執行順序

查詢語句中select from where group by having order by的執行順序

 

1.查詢中用到的關鍵詞主要包含六個，而且他們的順序依次爲 

select--from--where--group by--having--order by 

 

其中select和from是必須的，其餘關鍵詞是可選的，這六個關鍵詞的執行順序 

與sql語句的書寫順序並非同樣的，而是按照下面的順序來執行 

from--where--group by--having--select--order by, 

from:須要從哪一個數據表檢索數據 

where:過濾表中數據的條件 

group by:如何將上面過濾出的數據分組 

having:對上面已經分組的數據進行過濾的條件  

select:查看結果集中的哪一個列，或列的計算結果 

order by :按照什麼樣的順序來查看返回的數據 

 

2.from後面的表關聯，是自右向左解析的 

而where條件的解析順序是自下而上的。 

也就是說，在寫SQL文的時候，儘可能把數據量大的表放在最右邊來進行關聯， 

而把能篩選出大量數據的條件放在where語句的最下面。

from 子句--執行順序爲從後往前、從右到左
表名(最後面的那個表名爲驅動表，執行順序爲從後往前, 因此數據量較少的表儘可能放後）

按照從右到左的順序處理，FROM 子句中的表名，FROM 子句中寫在最後的表(基礎表 driving table)將被最早處理，即最後的表爲驅動表，在FROM 子句中包含多個表的狀況下,你必須選擇記錄條數最少的表做爲基礎表。若是有3 個以上的錶鏈接查詢, 那就須要選擇交叉表(intersection table)做爲基礎表, 交叉表是指被其餘表所引用的表

多表鏈接時，使用表的別名並把別名前綴於每一個Column上。能夠減小解析的時間並減小那些由Column 歧義引發的語法錯誤.

where子句（執行順序爲自下而上、從右到左）

根據這個原理,表之間的鏈接必須寫在其餘Where 條件以前, 能夠過濾掉最大數量記錄的條件必須寫在Where 子句的末尾。

group by（執行順序從左往右分組）

提升GROUP BY 語句的效率, 能夠經過將不須要的記錄在GROUP BY 以前過濾掉。即在GROUP BY前使用WHERE來過慮，而儘可能避免GROUP BY後再HAVING過濾。

having 子句（很耗資源，儘可能少用）

避免使用HAVING 子句, HAVING 只會在檢索出全部記錄以後纔對結果集進行過濾. 這個處理須要排序,總計等操做.

若是能經過Where 子句在GROUP BY前限制記錄的數目,那就能減小這方面的開銷.
(非oracle 中)on、where、having 這三個均可以加條件的子句中，on 是最早執行，where 次之，having 最後，由於on 是先把不符合條件的記錄過濾後才進行統計，它就能夠減小中間運算要處理的數據，按理說應該速度是最快的，

where 也應該比having 快點的，由於它過濾數據後才進行sum，在兩個表聯接時才用on 的，因此在一個表的時候，就剩下where 跟having比較了。

在這單表查詢統計的狀況下，若是要過濾的條件沒有涉及到要計算字段，那它們的結果是同樣的，只是where 可使用rushmore 技術，而having 就不能，在速度上後者要慢。
若是要涉及到計算的字段，就表示在沒計算以前，這個字段的值是不肯定的，where 的做用時間是在計算以前就完成的，而having 就是在計算後才起做用的，因此在這種狀況下，二者的結果會不一樣。

在多表聯接查詢時，on 比where 更早起做用。系統首先根據各個表之間的聯接條件，把多個表合成一個臨時表後，再由where 進行過濾，而後再計算，計算完後再由having 進行過濾。

因而可知，要想過濾條件起到正確的做用，首先要明白這個條件應該在何時起做用，而後再決定放在那裏。

select子句（少用*號，儘可能取字段名稱。）

數據庫解析的過程當中, 會將依次轉換成全部的列名, 這個工做是經過查詢數據字典完成的, 使用列名意味着將減小消耗時間。

order by子句--執行順序爲從左到右排序,很耗資源