oracle werhe

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

1、from子句组装来自不同数据源的数据；
2、where子句基于指定的条件对记录行进行筛选；
3、group by子句将数据划分为多个分组；
4、使用聚集函数进行计算；
5、使用having子句筛选分组；
6、计算所有的表达式；
7、select 的字段；
8、使用order by对结果集进行排序。


实验一：证明了SQL的语法分析是从右到左的
实验二：证明了SQL条件的执行是从右到左的

在RBO优化器模式下，表应按结果记录数从大到小的顺序从左到右来排列，因为表间连接时，最右边的表会被放到嵌套循环的最外层。最外层的循环次数越少，效率越高。

1.ORACLE采用自下而上的顺序解析WHERE子句,根据这个原理,表之间的连接必须写在其他WHERE条件之前, 那些可以过滤掉最大数量记录的条件必须写在WHERE子句的末尾.
2.SELECT子句中避免使用’*’
当在SELECT子句中列出所有的COLUMN时,使用动态SQL列引用 ‘*’ 是一个方便的方法.可是,这是一个非常低效的方法. 实际上,ORACLE在解析的过程中, 会将’*’ 依次转换成所有的列名, 这个工作是通过查询数据字典完成的, 这意味着将耗费更多的时间.

3.使用表的别名(Alias)

当在SQL语句中连接多个表时, 请使用表的别名并把别名前缀于每个Column上.这样一来,就可以减少解析的时间并减少那些由Column歧义引起的语法错误.

=================
一、SQL语句准备执行阶段
当SQL 语句进入Oracle 的库缓存后
1) 语法检查：检查SQL 语句拼写是否正确和词序
2) 语义分析：核实所有的与数据字典不一致的表和列的名字
3) 轮廓存储检查：检查数据字典
4) 生成执行计划：使用基于成本的优化规则和数据字典中的统计表来决定最佳执行计划
5) 建立二进制代码--基于HASH函数的HASH值：基于执行计划
一旦为执行准备好了，SQL以后的执行将很快发生，因为Oracle认可同一个SQL语句，并且重用那些语句的执行。
然而，对于生成特殊的SQL 语句，或嵌入了文字变量的SQL 语句的系统，SQL 执行计划的生成时间就很重要了，
并且前一个执行计划通常不能够被重用。对那些连接了很多表的查询，Oracle 需要花费大量的时间来检测连接这些表的适当顺序。

二、sql执行顺序：
from 子句--执行顺序为从后往前、从右到左
表名(最后面的那个表名为驱动表，执行顺序为从后往前, 所以数据量较少的表尽量放后）
oracle 的解析器按照从右到左的顺序处理，FROM 子句中的表名，FROM 子句中写在最后的表(基础表 driving table)将被最先处理，即最后的表为驱动表，在FROM 子句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表。如果有3 个以上的表连接查询, 那就需要选择交叉表(intersection table)作为基础表, 交叉表是指被其他表所引用的表
多表连接时，使用表的别名并把别名前缀于每个Column上。可以减少解析的时间并减少那些由Column 歧义引起的语法错误.
▼
▼
where子句--执行顺序为自下而上、从右到左
ORACLE 采用自下而上从右到左的顺序解析Where 子句,根据这个原理,表之间的连接必须写在其他Where 条件之前, 可以过滤掉最大数量记录的条件必须写在Where 子句的末尾。
▼
▼
group by--执行顺序从左往右分组
提高GROUP BY 语句的效率, 可以通过将不需要的记录在GROUP BY 之前过滤掉。即在GROUP BY前使用WHERE来过虑，而尽量避免GROUP BY后再HAVING过滤。
▼
▼
having 子句----很耗资源，尽量少用
避免使用HAVING 子句, HAVING 只会在检索出所有记录之后才对结果集进行过滤. 这个处理需要排序,总计等操作.
如果能通过Where 子句在GROUP BY前限制记录的数目,那就能减少这方面的开销.
(非oracle 中)on、where、having 这三个都可以加条件的子句中，on 是最先执行，where 次之，having 最后，因为on 是先把不符合条件的记录过滤后才进行统计，它就可以减少中间运算要处理的数据，按理说应该速度是最快的，
where 也应该比having 快点的，因为它过滤数据后才进行sum，在两个表联接时才用on 的，所以在一个表的时候，就剩下where 跟having比较了。
在这单表查询统计的情况下，如果要过滤的条件没有涉及到要计算字段，那它们的结果是一样的，只是where 可以使用rushmore 技术，而having 就不能，在速度上后者要慢。
如果要涉及到计算的字段，就表示在没计算之前，这个字段的值是不确定的，where 的作用时间是在计算之前就完成的，而having 就是在计算后才起作用的，所以在这种情况下，两者的结果会不同。
在多表联接查询时，on 比where 更早起作用。系统首先根据各个表之间的联接条件，把多个表合成一个临时表后，再由where 进行过滤，然后再计算，计算完后再由having 进行过滤。
由此可见，要想过滤条件起到正确的作用，首先要明白这个条件应该在什么时候起作用，然后再决定放在那里。
▼
▼
select子句--少用*号，尽量取字段名称。
ORACLE 在解析的过程中, 会将依次转换成所有的列名, 这个工作是通过查询数据字典完成的, 使用列名意味着将减少消耗时间。
sql 语句用大写的；因为 oracle 总是先解析 sql 语句，把小写的字母转换成大写的再执行
▼
▼
order by子句--执行顺序为从左到右排序,很耗资源



========================
sql 执行顺序

博客分类： Oracle数据库
sql
最近在网上学习到的一些到的知识。
在查询中逻辑查询和物理查询有着本质的区别，SQL不同于其它编程的最明显的特征就是处理代码的顺序，虽然总是最先写SELECT 但是几乎总在最后执行，那到底是怎么一个执行顺序呢
如下的sql查询语句执行顺序
(1)from
(3) join
(2) on
(4) where
(5)group by
(6) with
(7)having
(8) select
(9) distinct
(10) order by

    从这个顺序中我们不难发现，所有的 查询语句都是从from开始执行的，在执行过程中，每个步骤都会为下一个步骤生成一个虚拟表，这个虚拟表将作为下一个执行步骤的输入。
第一步：首先对from子句中的前两个表执行一个笛卡尔乘积，此时生成虚拟表 vt1（选择相对小的表做基础表）
第二步：接下来便是应用on筛选器，on 中的逻辑表达式将应用到 vt1 中的各个行，筛选出满足on逻辑表达式的行，生成虚拟表 vt2
第三步：如果是outer join 那么这一步就将添加外部行，left outer jion 就把左表在第二步中过滤的添加进来，如果是right outer join 那么就将右表在第二步中过滤掉的行添加进来，这样生成虚拟表 vt3
第四步：如果 from 子句中的表数目多余两个表，那么就将vt3和第三个表连接从而计算笛卡尔乘积，生成虚拟表，该过程就是一个重复1-3的步骤，最终得到一个新的虚拟表 vt3。
第五步：应用where筛选器，对上一步生产的虚拟表引用where筛选器，生成虚拟表vt4，在这有个比较重要的细节不得不说一下，对于包含outer join子句的查询，就有一个让人感到困惑的问题，到底在on筛选器还是用where筛选器指定逻辑表达式呢？on和where的最大区别在于，如果在on应用逻辑表达式那么在第三步outer join中还可以把移除的行再次添加回来，而where的移除的最终的。举个简单的例子，有一个学生表（班级,姓名）和一个成绩表(姓名,成绩)，我现在需要返回一个x班级的全体同学的成绩，但是这个班级有几个学生缺考，也就是说在成绩表中没有记录。为了得到我们预期的结果我们就需要在on子句指定学生和成绩表的关系（学生.姓名=成绩.姓名）那么我们是否发现在执行第二步的时候，对于没有参加考试的学生记录就不会出现在vt2中，因为他们被on的逻辑表达式过滤掉了,但是我们用left outer join就可以把左表（学生）中没有参加考试的学生找回来，因为我们想返回的是x班级的所有学生，如果在on中应用学生.班级='x'的话，那么在left outer join 中就会将不会把x班级的学生的所有记录找回来，所以只能在where筛选器中应用学生.班级='x' 因为它的过滤是最终的。
第六步：group by 子句将中的唯一的值组合成为一组，得到虚拟表vt5。如果应用了group by，那么后面的所有步骤都只能得到的vt5的列或者是聚合函数（count、sum、avg等）。原因在于最终的结果集中只为每个组包含一行。这一点请牢记。
第七步：应用cube或者rollup选项，为vt5生成超组，生成vt6.
第八步：应用having筛选器，生成vt7。having筛选器是第一个也是为唯一一个应用到已分组数据的筛选器。
第九步：处理select列表。将vt7中的在select中出现的列筛选出来。生成vt8.
第十步：应用distinct子句，vt8中移除相同的行，生成vt9。事实上如果应用了group by子句那么distinct是多余的，原因同样在于，分组的时候是将列中唯一的值分成一组，同时只为每一组返回一行记录，那么所以的记录都将是不相同的。
第十一步：应用order by子句。按照order_by_condition排序vt9，此时返回的一个游标，而不是虚拟表。sql是基于集合的理论的，集合不会预先对他的行排序，它只是成员的逻辑集合，成员的顺序是无关紧要的。对表进行排序的查询可以返回一个对象，这个对象包含特定的物理顺序的逻辑组织。这个对象就叫游标。正因为返回值是游标，那么使用order by 子句查询不能应用于表表达式。排序是很需要成本的，除非你必须要排序，否则最好不要指定order by，最后，在这一步中是第一个也是唯一一个可以使用select列表中别名的步骤。
第十二步：应用top选项。此时才返回结果给请求者即用户。

SQL where 条件顺序对性能的影响有哪些

经常有人问到oracle中的Where子句的条件书写顺序是否对SQL性能有影响，我的直觉是没有影响，因为如果这个顺序有影响，Oracle应该早就能够做到自动优化，但一直没有关于这方面的确凿证据。在网上查到的文章，一般认为在RBO优化器模式下无影响（10G开始，缺省为RBO优化器模式），而在CBO优化器模式下有影响，主要有两种观点：
　　a.能使结果最少的条件放在最右边，SQL执行是按从右到左进行结果集的筛选的；
　　b.有人试验表明，能使结果最少的条件放在最左边，SQL性能更高。
　　查过oracle8到11G的在线文档，关于SQL优化相关章节，没有任何文档说过where子句中的条件对SQL性能有影响，到底哪种观点是对的，没有一种确切的结论，只好自己来做实验证明。结果表明，SQL条件的执行是从右到左的，但条件的顺序对SQL性能没有影响。
　　实验一：证明了SQL的语法分析是从右到左的
　　下面的试验在9i和10G都可以得到相同的结果： 第1条语句执行不会出错，第2条语句会提示除数不能为零。
　
Sql代码  收藏代码
1.Select 'ok' From Dual Where 1 / 0 = 1 And 1 = 2; 
2.Select 'ok' From Dual Where 1 = 2 And 1 / 0 = 1; 

　　证明了SQL的语法分析是从右到左的。
　　实验二：证明了SQL条件的执行是从右到左的

Sql代码  收藏代码
drop table temp; 
create table temp( t1 varchar2(10),t2 varchar2(10)); 
insert into temp values('zm','abcde'); 
insert into temp values('sz','1'); 
insert into temp values('sz','2'); 
commit; 
1. select * from temp where to_number(t2)>1 and t1='sz'; 
2. select * from temp where t1='sz' and to_number(t2)>1; 


　　在9i上执行, 第1条语句执行不会出错，第2条语句会提示“无效的数字”
　　在10G上执行，两条语句都不会出错。
　　说明：9i上，SQL条件的执行确实是从右到左的，但是10G做了什么调整呢？
　　实验三：证明了在10g上SQL条件的执行是从右到左的

Sql代码  收藏代码
Create Or Replace Function F1(v_In Varchar2) Return Varchar2 Is 
Begin 
Dbms_Output.Put_Line('exec F1'); 
Return v_In; 
End F1; 
/ 
Create Or Replace Function F2(v_In Varchar2) Return Varchar2 Is 
Begin 
Dbms_Output.Put_Line('exec F2'); 
Return v_In; 
End F2; 
/ 
SQL> set serverout on; 
SQL> select 1 from dual where f1('1')='1' and f2('1')='1'; 
1 
---------- 
1 
exec F2 
exec F1 
SQL> select 1 from dual where f2('1')='1' and f1('1')='1'; 
1 
---------- 
1 
exec F1 
exec F2 


　　结果表明，SQL条件的执行顺序是从右到左的。
　　那么，根据这个结果来分析，把能使结果最少的条件放在最右边，是否会减少其它条件执行时所用的记录数量，从而提高性能呢？
　　例如：下面的SQL条件,是否应该调整SQL条件的顺序呢？

Sql代码  收藏代码
Where A.结帐id Is Not Null 
And A.记录状态<>0 
And A.记帐费用=1 
And (Nvl(A.实收金额, 0)<>Nvl(A.结帐金额, 0) Or Nvl(A.结帐金额, 0)=0) 
And A.病人ID=[1] And Instr([2],','||Nvl(A.主页ID,0)||',')>0 
And A.登记时间Between [3] And [4] 
And A.门诊标志<>1 


　　实际上，从这条SQL语句的执行计划来分析，Oracle首先会找出条件中使用索引或表间连接的条件，以此来过滤数据集，然后对这些结果数据块所涉及的记录逐一检查是否符合所有条件，所以条件顺序对性能几乎没有影响。
        如果没有索引和表间连接的情况，条件的顺序是否对性能有影响呢？再来看一个实验。
　　实验四：证明了条件的顺序对性能没有影响。

Sql代码  收藏代码
SQL> select count(*) from诊疗项目目录where操作类型='1'; 
COUNT(*) 
---------- 
3251 
SQL> select count(*) from诊疗项目目录where类别='Z'; 
COUNT(*) 
---------- 
170 
SQL> select count(*) from诊疗项目目录where类别='Z' and操作类型='1'; 
COUNT(*) 
---------- 
1 
Declare 
V1 Varchar2(20); 
Begin 
For I In 1 .. 1000 Loop 
--Select名称Into V1 From诊疗项目目录Where类别= 'Z' And操作类型= '1'; 
select名称Into V1 from诊疗项目目录where操作类型='1' and类别='Z'; 
End Loop; 
End; 
/ 


　　上面的SQL按两种方式分别执行了1000次查询，结果如下：
　　操作类型= '1'在最右|类别='Z'在最右
　　
Sql代码  收藏代码
  0.093                            |      1.014 
1.06                             |      0.999 
0.998                            |      1.014 

　　按理说，从右到左的顺序执行，“类别='Z'”在最右边时，先过滤得到170条记录，再从中找符合“操作类型 = '1'”的，比较而言，“操作类型 = '1'”在最右边时，先过滤得到3251条记录，再从中找符合“类别='Z'”，效率应该要低些，而实际结果却是两者所共的时间差不多。
　　其实，从Oracle的数据访问原理来分析，两种顺序的写法，执行计划都是一样的，都是全表扫描，都要依次访问该表的所有数据块，对每一个数据块中的行，逐一检查是否同时符合两个条件。所以，就不存在先过滤出多少条数据的问题。
　　综上所述，Where子句中条件的顺序对性能没有影响（不管是CBO还是RBO优化器模式），注意，额外说一下，这里只是说条件的顺序，不包含表的顺序。在RBO优化器模式下，表应按结果记录数从大到小的顺序从左到右来排列，因为表间连接时，最右边的表会被放到嵌套循环的最外层。最外层的循环次数越少，效率越高。