您所在的位置:首页 > 新闻中心 > sql执行步骤,Select语句执行顺序
公司要闻
sql执行步骤,Select语句执行顺序
发布时间:2020-04-02 17:45
访问量:359

0.sql的执行顺序
手写顺序
图片 1
机读顺序
图片 2
总结
图片 3
①From:对from左边的表和右边的表计算笛卡尔积,产生虚拟表c1
②On:对c1中的数据进行on过滤,只有符合过滤条件的数据记录才会记录在虚拟表c2中
③Join:若指定了连接条件(left、right),主表中的未匹配的行就会作为外部行添加到c2中,生成虚拟表c3
④Where:对虚拟表c3中的数据进行条件过滤,符合过滤条件的记录插入到虚拟表c4中
⑤Group by:根据group by子句中的列,对c4中的记录进行分组操作,生成c5
⑥Having:对虚拟表c5中的记录进行having过滤,符合筛选条件的记录插入虚拟表c6中
⑦Select:执行select操作,选择指定的列,插入到虚拟表c7中
⑧Distinct:对c7中的数据去重,生成虚拟表c8
⑨Order by:对虚拟表c8中的数据按照指定的排序规则进行排序,生成虚拟表c9
⑩Limit:取出指定的记录,产生虚拟表c10,将结果返回
1.join图
图片 4
2.数据准备
图片 5
①C、Z两表共有(交集部分)
Select * from tbl_emp inner join tal
图片 6
②C、Z共有+C的独有
图片 7
③ C、Z共有+Z的独有
图片 8
④C的独有
图片 9
⑤Z的独有
图片 10
⑥C的独有+Z的独有
图片 11
⑦AB全有
图片 12

AS sql_statement [ ...n ]

(1) FROM <left_table>

SQL执行步骤的具体分析,sql执行步骤

SQL执行步骤的具体分析

先来看执行语句的顺序

(8)select (9)distinct A (1)from Ta (3)join Tb 
(2)on XXX (4)where XXX (5)group by XXX (6)with 
{cube|roll up} (7)having XXX (10)order by XXX (11)limit XXX 

 接着我们看一下具体分析查询处理的各个阶段:

  1. FROM  对from子句中的左表和右表执行笛卡尔集,产生虚拟表VT1
  2. ON  对虚拟表VT1进行on筛选,只有那些符合join condition的行才被插入虚拟表VT2中
  3. JOIN  如果指定了outer join,那么保留表中未匹配的行作为外部行添加到虚拟表VT2中,产生虚拟表VT3。如果from子句包含两个以上的表,则对上一个连接生成的结果表中VT3和下一个表重复执行步骤1~步骤3,直到处理完所有的表为止。
  4. WHERE  对虚拟表VT3进行where过滤条件,只有符合条件的才被插入到虚拟表VT4中。
  5. GROUP BY  根据group by子句中的列,对VT4中的记录进行分组操作,产生VT5.
  6. CUBE|ROLL UP  对表VT5进行CUBE或者ROLLUP操作,产生表VT6.
  7. HAVING  对虚拟表VT6应用having过滤器,只有符合条件的记录才会被插入到虚拟表VT7中
  8. SELECT  第二次执行select操作,选择指定的列,插入到虚拟表VT8中。
  9. DISTINCT  去除重复数据,产生虚拟表VT9。
  10. ORDER BY  将虚拟表VT9中的记录按照指定的要求进行排序操作,产生虚拟表VT10
  11. LIMIT  取出指定行的记录,产生虚拟表VT11,并返回给查询用户

如有疑问请留言或者到本站社区交流讨论,感谢阅读,希望能帮助到大家,谢谢大家对本站的支持!

SQL执行步骤的具体分析 先来看执行语句的顺序 (8)select (9)distinct A (1)from Ta (3)join Tb (2)on XXX (4)where XXX...

关于Net提交的sql有无优化,暂无定论。但针对Net提交的Proc应该是优化执行了的。

(6) WITH {CUBE | ROLLUP}

#begin#

1、from子句组装来自不同数据源的数据; 

PS:

  7、 HAVING:对VT6应用HAVING筛选器,只有使为true的组插入到VT7。

Select (A.*) <----Compute Scalar <---- Sort <----Nested Loops/Inner Join |<----B.PK(Clustered Index Scan)

4、使用聚集函数进行计算; 

另外实践了:Select * from A ,B, C where xx and yy,也是优化了执行效果,同上一样。

(2) ON <join_condition>

  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,并返回调用者。

  逻辑查询处理阶段简介:

当然,这个是我假定的环境。实际上,如何验证这个效率还需要考究。

  9、 DISTINCT:将重复的行从VT8中删除,产品VT9。

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

FROM -> CONNECT BY -> WHERE -> GROUP BY -> HAVING -> SELECT -> ORDER BY

执行Left Join B

  8、 SELECT:处理SELECT列表,产生VT8。

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

  1、 FROM:对FROM子句中的前两个表执行笛卡尔积(交叉联接),生成虚拟表VT1。

另一文章:

 

此两句语句是不是这样执行呢?未可得知。

(7) HAVING <having_condition>

【搜索所得】:

2、where子句基于指定的条件对记录行进行筛选; 

标准的 SQL 的解析顺序为:
(1).FROM 子句, 组装来自不同数据源的数据
(2).WHERE 子句, 基于指定的条件对记录进行筛选
(3).GROUP BY 子句, 将数据划分为多个分组
(4).使用聚合函数进行计算
(5).使用 HAVING 子句筛选分组
(6).计算所有的表达式
(7).使用 ORDER BY 对结果集进行排序

(10) <TOP_specification> <select_list>

上述未有Select语句。

 

每个步骤都会产生一个虚拟表,该虚拟表被用作下一个步骤的输入。这些虚拟表对调用者(客户端应用程序或者外部查询)不可用。只是最后一步生成的表才会返回 给调用者。如果没有在查询中指定某一子句,将跳过相应的步骤。下面是对应用于SQL server 2000和SQL Server 2005的各个逻辑步骤的简单描述。

6、计算所有的表达式; 

此两句执行顺序是否一致??

  5、 GROUP BY:按GROUP BY子句中的列列表对TV4中的行进行分组,生成TV5。

这个结论有些似是而非。从侧面来说,查询分析器有一定的优化sql再执行

7、select 的字段;

比如:

(3) <join_type> JOIN <right_table>

Inner Join C On A.F2 = C.K

 

执行Select--VT6

  6、 CUTE|ROLLUP:把超组插入VT5,生成VT6。

无论怎么处理尽可能的让前3项过程性虚拟表更小些。

SQL Select语句完整的执行顺序: 

昨天调试一个存储过程,观察执行执行计划时发现:

  10、ORDER BY:将VT9中的行按ORDER BY子句中的列列表顺序,生成一个游标(VC10)。

执行On A.F2 = C.K--VT5

(5) GROUP BY <group_by_list>

A表无数据查询,A表聚合索引Scan,B表聚合索引Seek

(4) WHERE <where_condition>

执行From A,B,笛卡尔积产生1100000条记录的虚拟表VT1;

(9) ORDER BY <order_by_list>

A表有数据查询,B表聚合索引Scan,A表聚合索引Seek

  2、 ON:对VT1应用ON筛选器,只有那些使为真才被插入到TV2。

                                                                                                                  |<----B.PK(Clustered Index Seek)

 

执行 Inner join C

(9) DISTINCT

执行 Inner join C笛卡尔积VT3&C--VT4

where子句中的条件书写顺序:

从上述可以提问:

3、group by子句将数据划分为多个分组; 

A inner join c on yy 50w,再inner join b on xx得到10w

SQL语言不同于其他编程语言的最明显特征是处理代码的顺序。在大多数据库语言中,代码按编码顺序被处理。但在SQL语句中,第一个被处理的子句式FROM,而不是第一出现的SELECT。SQL查询处理的步骤序号:

【摘抄】

 

查阅一些网友结论,意思说:

  3、 OUTER (JOIN):如果指定了OUTER JOIN(相对于CROSS JOIN或INNER JOIN),保留表中未找到匹配的行将作为外部行添加到VT2,生成TV3。如果FROM子句包含两个以上的表,则对上一个联接生成的结果表和下一个表重复执行步骤1到步骤3,直到处理完所有的表位置。

                                                                                                            |<----A.PK(Clustered Index Seek)

5、使用having子句筛选分组; 

执行From A,只有一张表,那么只有1000条记录的虚拟表VT1;

(8) SELECT

查询分析器根据sql可以实际优化后执行,而net提交同一个sql也会优化么??

排序规则来着Query Processing Order.

关于此处实践情况:同样在查询分析器处理,查看执行计划

8、使用order by对结果集进行排序。

第一Sql语句执行效果应该是:

11、TOP:从VC10的开始处选择指定数量或比例的行,生成表TV11,并返回给调用者。

就近的On语句两表笛卡尔积,再On条件得新的虚拟表

  以上每个步骤都会产生一个虚拟表,该虚拟表被用作下一个步骤的输入。这些虚拟表对调用者(客户端应用程序或者外部查询)不可用。只有最后一步生成的表才会会给调用者。如果没有在查询中指定某一个子句,将跳过相应的步骤。

说明无此参数存储过程被缓存了。在查询器上执行效果也是缓存后执行的效果,而这个语句应该被查询分析器进行了执行优化的结果,那么Net提交也是由缓存中的存储过程执行

原文链接:SQL Select语句完整的执行顺序

  1. FROM clause
  2. WHERE clause
  3. GROUP BY clause
  4. HAVING clause
  5. SELECT clause
  6. ORDER BY clause

  4、 WHERE:对TV3应用WHERE筛选器,只有使为true的行才插入TV4。

PS:

暂时这么理解

执行From A

Select * from A inner join C on yy inner join b on XX

Left Join B On A.F1 = B.K

执行Where A.Key = B.Key,合符条件的进入到VT2(其条数不大于1100000);

[ WITH
    { RECOMPILE | ENCRYPTION | RECOMPILE , ENCRYPTION } ]

第二Sql语句执行效果应该是:

数据库,A表是呈现数据,B表是关联数据(B表有数据)

尽管看不出上述sql逻辑处理的顺序,估计在实际分析和编写select的时候需要参照

(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>

#end#

执行From A--VT1

个人理解:

暂时这么理解

无论Left Join在Inner Join前还是后,实际的执行计划都是A和C先处理,最后处理Left Join的B

尽管输出都是10w条数据

因为这一步不返回表(而是返回游标),使用了ORDER BY子句的查询不能用作表表达式。表表达式包括:视图、内联表值函数、子查询、派生表和共用表达式。它的结果必须返回给期望得到物理记录的客户端应用程序。

Inner Join B On A.Key = B.Key;

通过查询分析器运行执行计划,可见二者执行是一模一样

为了准确说明Select语句所在位置:

PS:

执行顺序又该如何??

那么我的认为:第二个sql语句效率高些

1、

执行Left Join B笛卡尔积VT1&B--VT2

结论:在查询分析器下,inner Join之间的表是无序的。

A inner join b on xx 100w,再inner join c on yy得到10w

难道第二Sql实际执行逻辑同前者?疑问中

Left Join B On A.F1 = B.K

PS:

执行On A.Key = B.Key,筛选满足条件的生成VT2(疑问?);

注:步骤10,按ORDER BY子句中的列列表排序上步返回的行,返回游标VC10.这一步是第一步也是唯一一步可以使用SELECT列表中的列别名的步骤。这一步不同于其它步骤的 是,它不返回有效的表,而是返回一个游标。SQL是基于集合理论的。集合不会预先对它的行排序,它只是成员的逻辑集合,成员的顺序无关紧要。对表进行排序 的查询可以返回一个对象,包含按特定物理顺序组织的行。ANSI把这种对象称为游标。理解这一步是正确理解SQL的基础。

Select * From A,B Where A.Key = B.Key;

A、B、C三表

在查询分析器执行一个sql,和Net提交同一个Sql执行的效率是不是一样的??

Select * From A

执行Select *,得到VT3,从而输出

Inner Join C On A.F2 = C.K

CREATE PROC [ EDURE ] procedure_name [ ; number ]
    [ { @parameter data_type }
        [ VARYING ] [ = default ] [ OUTPUT ]
    ] [ ,...n ]

定义A、B、C三表,数据量分别为1000、1100、1200条

同样优化过,优化结果是:从右到左,表的记录量都是尽量最小。

查询分析器实践:

不知道这么认为是不是错误的?

调整了索引之类

执行Select

目的在于理解如何Select

Select * From A

[ FOR REPLICATION ]

执行Join B,(如何执行?),生成VT3;

当有大量数据执行和无数据执行时,两个执行计划不一致;

另一类理解:

Select * From A

其中Recompile参数 表明 SQL Server 不会缓存该过程的计划,该过程将在运行时重新编译。在使用非典型值或临时值而不希望覆盖缓存在内存中的执行计划时,请使用 RECOMPILE 选项。

执行On A.F1 = B.K--VT3

今天再次执行,观察结果执行计划,出现:

Select (A.*) <----Compute Scalar <---- Sort <----Nested Loops/Left Semi Join |<----A.PK(Clustered Index Scan)

还是侧面证据:

至于原因是不是查询分析器优化过,估计优化结果类似这样:

执行On A.F2 = C.K

执行Select *,得到VT4,从而输出

按照前面所述执行顺序,

逻辑查询处理阶段简介

假定:

这么说,就和第一Sql执行一样了

2、

在MsSql2000查询分析器实践的表,都是有关键字的,并且建立了对应索引。

Select * from A inner join b on XX inner join C on yy

执行On A.F1 = B.K