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>

逻辑查询处理阶段简介

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子句的查询不能用作表表达式。表表达式包括：视图、内联表值函数、子查询、派生表和共用表达式。它的结果必须返回给期望得到物理记录的客户端应用程序。例如，下面的派生表查询无效，并产生一个错误：

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 是在执行的阶段发生的。