目的在於理解如何Select
【搜索所得】：
標準的 SQL 的解析順序爲:
(1).FROM 子句, 組裝來自不同數據源的數據
(2).WHERE 子句, 基於指定的條件對記錄進行篩選
(3).GROUP BY 子句, 將數據劃分爲多個分組
(4).使用聚合函數進行計算
(5).使用 HAVING 子句篩選分組
(6).計算所有的表達式
(7).使用 ORDER BY 對結果集進行排序
上述未有Select語句。
爲了準確說明Select語句所在位置：
1. FROM clause
2. WHERE clause
3. GROUP BY clause
4. HAVING clause
5. SELECT clause
6. ORDER BY clause
#begin#
另一文章：http://www.cnblogs.com/chinabc/articles/1597198.html
【摘抄】
每個步驟都會產生一個虛擬表，該虛擬表被用作下一個步驟的輸入。這些虛擬表對調用者（客戶端應用程序或者外部查詢）不可用。只是最後一步生成的表纔會返回 給調用者。如果沒有在查詢中指定某一子句，將跳過相應的步驟。下面是對應用於SQL server 2000和SQL Server 2005的各個邏輯步驟的簡單描述。
(1)FROM [left_table]
(3)<join_type> JOIN <right_table>
(2) ON <join_condition>
(4)WHERE <where_condition>
(5)GROUP BY <group_by_list>
(6)WITH <CUBE | RollUP>
(7)HAVING <having_condition>
(10)ORDER BY <order_by_list>
邏輯查詢處理階段簡介
- FROM：對FROM子句中的前兩個表執行笛卡爾積（Cartesian product)(交叉聯接），生成虛擬表VT1
- ON：對VT1應用ON篩選器。只有那些使<join_condition>爲真的行才被插入VT2。
- OUTER(JOIN)：如果指定了OUTER JOIN（相對於CROSS JOIN 或(INNER JOIN),保留表（preserved table：左外部聯接把左表標記爲保留表，右外部聯接把右表標記爲保留表，完全外部聯接把兩個表都標記爲保留表）中未找到匹配的行將作爲外部行添加到 VT2,生成VT3.如果FROM子句包含兩個以上的表，則對上一個聯接生成的結果表和下一個表重複執行步驟1到步驟3，直到處理完所有的表爲止。
- WHERE：對VT3應用WHERE篩選器。只有使<where_condition>爲true的行才被插入VT4.
- GROUP BY：按GROUP BY子句中的列列表對VT4中的行分組，生成VT5.
- CUBE|ROLLUP：把超組(Suppergroups)插入VT5,生成VT6.
- HAVING：對VT6應用HAVING篩選器。只有使<having_condition>爲true的組纔會被插入VT7.
- SELECT：處理SELECT列表，產生VT8.
- DISTINCT：將重複的行從VT8中移除，產生VT9.
- ORDER BY：將VT9中的行按ORDER BY 子句中的列列表排序，生成遊標（VC10).
- TOP：從VC10的開始處選擇指定數量或比例的行，生成表VT11,並返回調用者。
注：步驟10，按ORDER BY子句中的列列表排序上步返回的行，返回遊標VC10.這一步是第一步也是唯一一步可以使用SELECT列表中的列別名的步驟。這一步不同於其它步驟的 是，它不返回有效的表，而是返回一個遊標。SQL是基於集合理論的。集合不會預先對它的行排序，它只是成員的邏輯集合，成員的順序無關緊要。對錶進行排序 的查詢可以返回一個對象，包含按特定物理順序組織的行。ANSI把這種對象稱爲遊標。理解這一步是正確理解SQL的基礎。
因爲這一步不返回表（而是返回遊標），使用了ORDER BY子句的查詢不能用作表表達式。表表達式包括：視圖、內聯表值函數、子查詢、派生表和共用表達式。它的結果必須返回給期望得到物理記錄的客戶端應用程序。
#end#
從上述可以提問：
定義A、B、C三表，數據量分別爲1000、1100、1200條
1、
Select * From A,B Where A.Key = B.Key;
Select * From A
Inner Join B On A.Key = B.Key;
此兩句執行順序是否一致？？
個人理解：
按照前面所述執行順序，
第一Sql語句執行效果應該是：
執行From A,B，笛卡爾積產生1100000條記錄的虛擬表VT1；
執行Where A.Key = B.Key，合符條件的進入到VT2（其條數不大於1100000）；
執行Select *，得到VT3，從而輸出
第二Sql語句執行效果應該是：
執行From A，只有一張表，那麼只有1000條記錄的虛擬表VT1；
執行On A.Key = B.Key，篩選滿足條件的生成VT2（疑問？）；
執行Join B，（如何執行？），生成VT3；
執行Select *，得到VT4，從而輸出
此兩句語句是不是這樣執行呢？未可得知。
通過查詢分析器運行執行計劃，可見二者執行是一模一樣
難道第二Sql實際執行邏輯同前者？疑問中
PS：
查閱一些網友結論，意思說：
就近的On語句兩表笛卡爾積，再On條件得新的虛擬表
這麼說，就和第一Sql執行一樣了
暫時這麼理解
2、
Select * From A
Left Join B On A.F1 = B.K
Inner Join C On A.F2 = C.K
執行順序又該如何？？
執行From A
執行On A.F1 = B.K
執行Left Join B
執行On A.F2 = C.K
執行 Inner join C
執行Select
另一類理解：
執行From A--VT1
執行Left Join B笛卡爾積VT1&B--VT2
執行On A.F1 = B.K--VT3
執行 Inner join C笛卡爾積VT3&C--VT4
執行On A.F2 = C.K--VT5
執行Select--VT6
查詢分析器實踐：
無論Left Join在Inner Join前還是後，實際的執行計劃都是A和C先處理，最後處理Left Join的B
至於原因是不是查詢分析器優化過，估計優化結果類似這樣：
Select * From A
Inner Join C On A.F2 = C.K
Left Join B On A.F1 = B.K
暫時這麼理解
無論怎麼處理儘可能的讓前3項過程性虛擬表更小些。
比如：
A、B、C三表
Select * from A inner join b on XX inner join C on yy
Select * from A inner join C on yy inner join b on XX
儘管輸出都是10w條數據
假定：
A inner join b on xx 100w,再inner join c on yy得到10w
A inner join c on yy 50w,再inner join b on xx得到10w
那麼我的認爲：第二個sql語句效率高些
當然，這個是我假定的環境。實際上，如何驗證這個效率還需要考究。
關於此處實踐情況：同樣在查詢分析器處理，查看執行計劃
同樣優化過，優化結果是：從右到左，表的記錄量都是儘量最小。
另外實踐了：Select * from A ,B, C where xx and yy，也是優化了執行效果，同上一樣。
結論：在查詢分析器下，inner Join之間的表是無序的。
儘管看不出上述sql邏輯處理的順序，估計在實際分析和編寫select的時候需要參照
PS:
在MsSql2000查詢分析器實踐的表，都是有關鍵字的，並且建立了對應索引。
PS：
在查詢分析器執行一個sql，和Net提交同一個Sql執行的效率是不是一樣的？？
查詢分析器根據sql可以實際優化後執行，而net提交同一個sql也會優化麼？？
不知道這麼認爲是不是錯誤的？
PS:
昨天調試一個存儲過程，觀察執行執行計劃時發現：
當有大量數據執行和無數據執行時，兩個執行計劃不一致；
調整了索引之類
今天再次執行，觀察結果執行計劃，出現：
數據庫，A表是呈現數據，B表是關聯數據（B表有數據）
A表無數據查詢，A表聚合索引Scan，B表聚合索引Seek
Select (A.*) <----Compute Scalar <---- Sort <----Nested Loops/Left Semi Join |<----A.PK(Clustered Index Scan)
|<----B.PK(Clustered Index Seek)
A表有數據查詢，B表聚合索引Scan，A表聚合索引Seek
Select (A.*) <----Compute Scalar <---- Sort <----Nested Loops/Inner Join |<----B.PK(Clustered Index Scan)
|<----A.PK(Clustered Index Seek)
這個結論有些似是而非。從側面來說，查詢分析器有一定的優化sql再執行
關於Net提交的sql有無優化，暫無定論。但針對Net提交的Proc應該是優化執行了的。
還是側面證據：
CREATE PROC [ EDURE ] procedure_name [ ; number ]
[ { @parameter data_type }
[ VARYING ] [ = default ] [ OUTPUT ]
] [ ,...n ]
[ WITH
{ RECOMPILE | ENCRYPTION | RECOMPILE , ENCRYPTION } ]
[ FOR REPLICATION ]
AS sql_statement [ ...n ]
其中Recompile參數 表明 SQL Server 不會緩存該過程的計劃，該過程將在運行時重新編譯。在使用非典型值或臨時值而不希望覆蓋緩存在內存中的執行計劃時，請使用 RECOMPILE 選項。
說明無此參數存儲過程被緩存了。在查詢器上執行效果也是緩存後執行的效果，而這個語句應該被查詢分析器進行了執行優化的結果，那麼Net提交也是由緩存中的存儲過程執行
當然具體如何，我也無從判斷，暫定這麼思維
無論生活、還是技術，一切都不斷的學習和更新~~~努力~