sql执行顺序
 
 
 
 
 

   SQL 不同于与其他编程语言的最明显特征是处理代码的顺序。在大数编程语言中，代码按编码顺序被处理，但是在SQL语言中，第一个被处理的子句是FROM子句，尽管SELECT语句第一个出现，但是几乎总是最后被处理。 
  
      每个步骤都会产生一个虚拟表，该虚拟表被用作下一个步骤的输入。这些虚拟表对调用者（客户端应用程序或者外部查询）不可用。只是最后一步生成的表才会返回 给调用者。如果没有在查询中指定某一子句，将跳过相应的步骤。下面是对应用于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
   > 
   

    
   
 
  
 
  
逻辑查询处理阶段简介
 
  
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子句的查询不能用作表表达式。表表达式包括：视图、内联表值函数、子查询、派生表和共用表达式。它的结果必须返回给期望得到物理记录的客户端应用程序。例如，下面的派生表查询无效，并产生一个错误：
 
  
select * 
from(select orderid,customerid from orders order by orderid) 
as d
 
  
下面的视图也会产生错误
 
  
create view my_view
as
select *
from orders
order by orderid
 
  
      在SQL中，表表达式中不允许使用带有ORDER BY子句的查询，而在T—SQL中却有一个例外（应用TOP选项）。
 
  
      所以要记住，不要为表中的行假设任何特定的顺序。换句话说，除非你确定要有序行，否则不要指定ORDER BY 子句。排序是需要成本的，SQL Server需要执行有序索引扫描或使用排序运行符。
 
  

 
 
  
 
  
 
   
 
    
 Oracle中SQL语句执行过程中,Oracle内部解析原理如下:
 
    
 　　1、当一用户第一次提交一个SQL表达式时,Oracle会将这SQL进行Hard parse,这过程有点像程序编译,检查语法、表名、字段名等相关信息（如下图），这过程会花比较长的时间，因为它要分析语句的语法与语义。然后获得最优化后的执行计划（sql plan），并在内存中分配一定的空间保存该语句与对应的执行计划等信息。
 
    
  
 
    
 　　2、当用户第二次请求或多次请求时，Oracle会自动找到先前的语句与执行计划，而不会进行Hard parse,而是直接进行Soft parse（把语句对应的执行计划调出，然后执行）,从而减少数据库的分析时间。
 
    
  
 
    
 　　注意的是：Oracle中只能完全相同的语句，包大小写、空格、换行都要求一样时，才会重复使用以前的分析结果与执行计划。
 
    
  
 
    
 　　分析过程如下图：
 
    
 
 
    
  对于大量的、频繁访问的SQL语句，如果不采用Bind 变量的方式，哪Oracle会花费大量的Shared latch与CPU在做Hard parse处理，所以，要尽量提高语句的重用率，减少语句的分析时间，通过了解Oracle SQL语句的分析过程可以明白Oracle的内部处理逻辑，并在设计与实现上避免。
 
    
  
 
    
 在用JDBC或其它持久化数据(如Hibernate,JDO等)操作时，尽量用占位符（？）
 
    
  
 
    
 ORACLE sql 的处理过程大致如下：
 
    
  1.运用HASH算法，得到一个HASH值，这个值可以通过V$SQLAREA.HASH_VALUE 查看
 
    
  2.到shared pool 中的 library cache 中查找是否有相同的HASH值，如果存在，则无需硬解析，进行软解析
 
    
  3.如果shared pool不存在此HASH值，则进行语法检查，查看是否有语法错误
 
    
  4.如果没有语法错误，就进行语义检查，检查该SQL引用的对象是否存在，该用户是否具有访问该对象的权限
 
    
  5.如果没有语义错误，对该SQL进行解析，生成解析树，执行计划
 
    
  6.生成ORACLE能运行的二进制代码，运行该代码并且返回结果给用户
 
    
 硬解析和软解析都在第5步进行
 
    
 硬解析通常是昂贵的操作，大约占整个SQL执行的70%左右的时间，硬解析会生成执行树，执行计划，等等。
 
    
 当再次执行同一条SQL语句的时候，由于发现library cache中有相同的HASH值，这个时候不会硬解析，而会软解析，
 
    
 那么软解析究竟是干了什么呢?其实软解析就是跳过了生成解析树，生成执行计划这个耗时又耗CPU的操作，直接利用生成的执行计划运行
 
    
 该SQL语句。
 
    
 下面摘抄eygle深入解析ORACLE 中关于SQL执行过程的描述
 
    
   1.首先获得library cache latch,根据SQL的HASH_VALUE在library cache中查找是否存在此HASH_VALUE，如果找到这个HASH_VALUE，称之为软解析，Server获得改SQL执行计划转向第4步，如果找不到共享代码就进行硬解析。
 
    
   2.释放library pool cache,获得shared pool latch,查找并锁定自由空间(在bucket 中查找chunk)。如果找不到，报ORA-04031错误。
 
    
   3.释放shared pool latch,重新获得library cache latch,将SQL执行计划放入library cache中。
 
    
   4.释放library cache latch,保持null模式的library cache pin/lock。
 
    
   5.开始执行。
 
    
 Library cache latch可以理解为硬/软解析的时候发生的，因为解析的时候会搜索library cache，所以会产生library cache latch
 
    
 Library cache pin 是在执行的阶段发生的。
 
    

     
 
    
 
   
 
  
 
  
   
  
 
  
 
  
 
  
 
 
 

一.Spark SQL模板解析
 
   Spark Sql 关键字执行顺序跟Sql执行顺序类似:
 
1.先将from前两表做笛卡尔积加载进来形成虚拟表vt1,
 
2.on条件后为真的插入虚拟表形成vt2,
 
如果包含多个表,重复操作,
 
完成所有数据加载后, 开始对形成的大虚拟表vt2进行处理, 
 
3.where 后为真的插入vt3
 
4.group by 进行行分组形成vt4
 
5.cube|roll up:超组形成vt5
 
6. HIving: 为true的插入vt6
 
7.select :形成vt7
 
8.distinct:形成vt8
 
10.order by形成vt9
 
11.top:形成vt10

（1）、SQL执行顺序
 
手写
 
 
机读
 
随着Mysql版本的更新换代，其优化器也在不断的升级，优化器会分析不同执行顺序产生的性能消耗不同而动态调整执行顺序。
 
下面是经常出现的查询顺序：
 
 
总结
 
 
（2）、JOIN图
 
 

数据库中SQL的执行顺序如下：
 
(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>
 
每个步骤都会产生一个虚拟表，该虚拟表被用作下一个步骤的输入。这些虚拟表对调用者（客户端应用程序或者外部查询）不可用。只是最后一步生成的表才会返回给调用者。如果没有在查询中指定某一子句，将跳过相应的步骤。
 
逻辑查询处理阶段简介
 
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,并返回调用者。
<<<文章内容主要摘自https://www.cnblogs.com/XiaoZone/p/7851898.html >>>