今天在寫一條語句的時候，在查詢分析器里邊執(zhí)行
要用10s，換用另外一種寫法只用少于1s的時間，同事說是因為Sql句語執(zhí)行順序的原因。之前看過一點相
關的書，有一點印象，到網上找了資料，學習下。
邏輯查詢處理步驟

每個步驟產生一個虛擬表，該虛擬表被用作下一個步驟的輸入。只有最后一步生成的表返回給調用者。如
果沒有某一子句，則跳過相應的步驟。
1. FROM:對FROM子句中的前兩個表執(zhí)行笛卡爾積，生成虛擬表VT1。
2. ON:對VT1應用ON篩選器。只有那些使<join_condition>為真的行才被插入VT2。
3. OUTER(JOIN):如果指定了OUTER JOIN，保留表中未找到匹配的行將作為外部行添加到VT2，生成VT3。
如果FROM子句包含兩個以上的表，則對上一個聯(lián)接生成的結果表和下一個表重復執(zhí)行步驟1到步驟3，直到
處理完所有的表為止。
4. 對VT3應用WHERE篩選器。只有使<where_condition>為TRUE的行才被插入VT4。
5. GROUP BY:按GROUP BY 子句中的列列表對VT4中的行分組，生成VT5。
6. CUBE|ROLLUP:把超組插入VT5，生成VT6。
7. HAVING:對VT6應用HAVING篩選器。只有使<having_condition>為TRUE的組才會被插入VT7。
8. SELECT:處理SELECT列表，產生VT8。
9. DISTINCT:將重復的行從VT8中移除，產生VT9。
10. ORDER BY:將VT9中的行按ORDER BY子句中的列列表排序，生成一個有表(VC10)。
11. TOP:從VC10的開始處選擇指定數(shù)量或比例的行，生成表VT11,并返回給調用者。
以下是其它網友的補充:
好像自已在書寫 SQL 語句時由于不清楚各個關鍵字的執(zhí)行順序, 往往組織的 SQL 語句缺少很好的邏輯, 憑感覺 "拼湊" ( 不好意思, 如果您的 SQL 語句也經常 "拼湊", 那您是不是得好好反省一下呢?, 呵呵).
這樣做確實是爽了自己, 可苦了機器, 服務器還需要在我們的雜亂無章的 SQL 語句中尋找它下一句需要執(zhí)行的關鍵字在哪里.
效率嘛, 由于我們的感覺神經對秒以下的變化實在不敏感, 暫且就認為自已寫的 SQL 順序無關緊要, "反正沒什么變化!", 呵呵.其實服務器對每句 SQL 解析時間都會有詳細記錄的, 大家可以看一下自已按習慣寫的 SQL 和按標準順序寫的SQL解析時間差別有多大.
因此, 建議大家在平時工作中 SQL 語句按標準順序寫, 一是專業(yè), 二是實用, 呵呵, 不過我覺得最主要的是心里感覺舒服.
標準的 SQL 的解析順序為:
(1).FROM 子句, 組裝來自不同數(shù)據(jù)源的數(shù)據(jù)
(2).WHERE 子句, 基于指定的條件對記錄進行篩選
(3).GROUP BY 子句, 將數(shù)據(jù)劃分為多個分組
(4).使用聚合函數(shù)進行計算
(5).使用 HAVING 子句篩選分組
(6).計算所有的表達式
(7).使用 ORDER BY 對結果集進行排序
舉例說明: 在學生成績表中 (暫記為 tb_Grade), 把 "考生姓名"內容不為空的記錄按照 "考生姓名" 分組, 并且篩選分組結果, 選出 "總成績" 大于 600 分的.
標準順序的 SQL 語句為:
select 考生姓名, max(總成績) as max總成績
from tb_Grade
where 考生姓名 is not null
group by 考生姓名
having max(總成績) > 600
order by max總成績
在上面的示例中 SQL 語句的執(zhí)行順序如下:
(1). 首先執(zhí)行 FROM 子句, 從 tb_Grade 表組裝數(shù)據(jù)源的數(shù)據(jù)
(2). 執(zhí)行 WHERE 子句, 篩選 tb_Grade 表中所有數(shù)據(jù)不為 NULL 的數(shù)據(jù)
(3). 執(zhí)行 GROUP BY 子句, 把 tb_Grade 表按 "學生姓名" 列進行分組
(4). 計算 max() 聚集函數(shù), 按 "總成績" 求出總成績中最大的一些數(shù)值
(5). 執(zhí)行 HAVING 子句, 篩選課程的總成績大于 600 分的.
(7). 執(zhí)行 ORDER BY 子句, 把最后的結果按 "Max 成績" 進行排序.
好了，看了這些之后，我相信大家都知道了SQL中select語句的執(zhí)行順序了吧！哈哈！

最新評論