Select语句执行各样《转》

原文公布时吗: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子句被的面前少单表达执行笛Carl积(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,笛卡尔(Carl)积爆发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语句简单表达笛卡尔(Carl)积,再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笛Carl积VT1&B–VT2

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

执行 Inner join C笛Carl积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提交也是由缓存中的积存过程举行

本具体哪些,我哉不可能判断,暂定这么想

相关文章