原文发布时间为：2010-10-12 —— 来源于本人的百度文章 [由搬家工具导入]

目的在于理解如何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的各个逻辑步骤的简单描述。

(8)SELECT (9)DISTINCT   (11)<Top Num> <select list>
(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>

逻辑查询处理阶段简介

1. FROM：对FROM子句中的前两个表执行笛卡尔积（Cartesian product)(交叉联接），生成虚拟表VT1
2. ON：对VT1应用ON筛选器。只有那些使<join_condition>为真的行才被插入VT2。
3. OUTER(JOIN)：如果指定了OUTER JOIN（相对于CROSS JOIN 或(INNER JOIN),保留表（preserved table：左外部联接把左表标记为保留表，右外部联接把右表标记为保留表，完全外部联接把两个表都标记为保留表）中未找到匹配的行将作为外部行添加到 VT2,生成VT3.如果FROM子句包含两个以上的表，则对上一个联接生成的结果表和下一个表重复执行步骤1到步骤3，直到处理完所有的表为止。
4. WHERE：对VT3应用WHERE筛选器。只有使<where_condition>为true的行才被插入VT4.
5. GROUP BY：按GROUP BY子句中的列列表对VT4中的行分组，生成VT5.
6. CUBE|ROLLUP：把超组(Suppergroups)插入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的开始处选择指定数量或比例的行，生成表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提交也是由缓存中的存储过程执行

当然具体如何，我也无从判断，暂定这么思维