下载文档原格式
oracle 慢sql查询语句慢SQL查询是指执行时间较长的SQL查询语句，通常会对数据库性能产生负面影响。
在Oracle数据库中，出现慢SQL查询的原因可能有很多，例如查询条件不合理、索引缺失、数据量过大等。
下面列举了一些常见的慢SQL查询场景及相应的优化建议。
1. 慢SQL查询场景：未使用索引进行查询优化建议：通过查看执行计划，确认是否存在索引缺失的情况。
可以通过创建合适的索引来提高查询性能。
2. 慢SQL查询场景：使用了模糊查询优化建议：模糊查询通常会导致全表扫描，影响查询性能。
可以考虑使用全文索引或者优化查询条件，减少模糊匹配的范围。
3. 慢SQL查询场景：大表关联查询优化建议：大表关联查询会导致临时表的产生以及大量的磁盘IO，影响查询性能。
可以考虑使用分页查询或者优化查询逻辑，减少关联表的数量。
4. 慢SQL查询场景：使用了函数或表达式优化建议：函数或表达式的使用会导致在查询执行过程中进行计算，影响查询性能。
可以考虑将计算逻辑提前计算好，存储在数据库中，避免重复计算。
5. 慢SQL查询场景：大量数据的排序查询优化建议：大量数据的排序查询可能会导致临时表的产生以及大量的磁盘IO，影响查询性能。
可以通过创建排序索引或者优化查询条件，减少排序的数据量。
6. 慢SQL查询场景：查询结果集过大优化建议：查询结果集过大会占用大量的内存资源，影响查询性能。
可以通过分页查询或者优化查询条件，减少查询结果集的大小。
7. 慢SQL查询场景：频繁的表锁竞争优化建议：频繁的表锁竞争会导致查询阻塞，影响查询性能。
可以通过合理设计数据库表结构、调整事务隔离级别或者优化查询逻辑，减少表锁竞争的情况。
8. 慢SQL查询场景：存在死锁问题优化建议：死锁问题会导致查询阻塞，影响查询性能。
可以通过合理设计数据库表结构、调整事务隔离级别或者优化查询逻辑，避免死锁问题的发生。
9. 慢SQL查询场景：查询语句过于复杂优化建议：过于复杂的查询语句会导致查询优化器无法选择最优执行计划，影响查询性能。
查看ORACLE执⾏计划的⼏种常⽤⽅法SQL的执⾏计划实际代表了⽬标SQL在Oracle数据库内部的具体执⾏步骤，作为调优，只有知道了优化器选择的执⾏计划是否为当前情形下最优的执⾏计划，才能够知道下⼀步往什么⽅向。
执⾏计划的定义：执⾏⽬标SQL的所有步骤的组合。
我们⾸先列出查看执⾏计划的⼀些常⽤⽅法：1. explain plan命令PL/SQL Developer中通过快捷键F5就可以查看⽬标SQL的执⾏计划了。
但其实按下F5后，实际后台调⽤的就是explain plan命令，相当于封装了该命令。
explain plan使⽤⽅法：(1) 执⾏explain plan for + SQL(2) 执⾏select * from table(dbms_xplan.display);实验表准备：SQL> desc test1;Name Null Type----------------------------------------- -------- ----------------------------T1ID NOT NULL NUMBER(38)T1V VARCHAR2(10)SQL> desc test2;Name Null Type----------------------------------------- -------- ----------------------------T2ID NOT NULL NUMBER(38)T2V VARCHAR2(10)实验：SQL> set linesize 100SQL> explain plan for select t1id, t1v, t2id, t2v from test1, test2 where test1.t1id = test2.t2id;Explained.第⼀步使⽤explain plan对⽬标SQL进⾏了explain，第⼆步使⽤select * from table(dbms_xplan.display)语句展⽰出该SQL的执⾏计划。
oracle sql 优化技巧（实用版3篇）目录（篇1）1.Oracle SQL 简介2.优化技巧2.1 减少访问数据库次数2.2 选择最有效率的表名顺序2.3 避免使用 SELECT2.4 利用 DECODE 函数2.5 设置 ARRAYSIZE 参数2.6 使用 TRUNCATE 替代 DELETE2.7 多使用 COMMIT 命令2.8 合理使用索引正文（篇1）Oracle SQL 是一款广泛应用于各类大、中、小微机环境的高效、可靠的关系数据库管理系统。
为了提高 Oracle SQL 的性能，本文将为您介绍一些优化技巧。
首先，减少访问数据库的次数是最基本的优化方法。
Oracle 在内部执行了许多工作，如解析 SQL 语句、估算索引的利用率、读数据块等，这些都会大量耗费 Oracle 数据库的运行。
因此，尽量减少访问数据库的次数，可以有效提高系统性能。
其次，选择最有效率的表名顺序也可以明显提升 Oracle 的性能。
Oracle 解析器是按照从右到左的顺序处理 FROM 子句中的表名，因此，合理安排表名顺序，可以减少解析时间，提高查询效率。
在执行 SELECT 子句时，应尽量避免使用，因为 Oracle 在解析的过程中，会将依次转换成列名，这是通过查询数据字典完成的，耗费时间较长。
DECODE 函数也是一个很好的优化工具，它可以避免重复扫描相同记录，或者重复连接相同的表，提高查询效率。
在 SQLPlus 和 SQLForms 以及 ProC 中，可以重新设置 ARRAYSIZE 参数。
该参数可以明显增加每次数据库访问时的检索数据量，从而提高系统性能。
建议将该参数设置为 200。
当需要删除数据时，尽量使用 TRUNCATE 语句替代 DELETE 语句。
执行 TRUNCATE 命令时，回滚段不会存放任何可被恢复的信息，所有数据不能被恢复。
因此，TRUNCATE 命令执行时间短，且资源消耗少。
在使用 Oracle 时，尽量多使用 COMMIT 命令。
oracle sql 跟踪方法Oracle SQL是一种强大的关系型数据库管理系统，它提供了一套丰富的工具和功能来跟踪和分析SQL语句的执行过程。
在开发和调试过程中，跟踪SQL语句的执行可以帮助我们快速定位问题并进行优化。
本文将介绍几种常用的Oracle SQL跟踪方法。
一、使用SQL Trace跟踪方法SQL Trace是Oracle提供的一种跟踪SQL语句执行过程的方法。
通过在会话级别启用SQL Trace，我们可以收集SQL语句的执行计划、消耗的资源以及其他相关信息。
启用SQL Trace的方法如下：1. 使用ALTER SESSION语句启用SQL Trace：ALTER SESSION SET SQL_TRACE = TRUE;2. 使用DBMS_SESSION包启用SQL Trace：EXEC DBMS_SESSION.SET_SQL_TRACE(TRUE);启用SQL Trace后，Oracle将会将跟踪信息写入跟踪文件中。
我们可以使用以下方法查找跟踪文件的位置：1. 查询V$DIAG_INFO视图获取跟踪文件的位置：SELECT VALUE FROM V$DIAG_INFO WHERE NAME = 'Default Trace File';2. 查询USER_DUMP_DEST或BACKGROUND_DUMP_DEST参数获取跟踪文件的位置：SELECT VALUE FROM V$PARAMETER WHERE NAME = 'user_dump_dest';跟踪文件的命名方式为ORA_SID_PID.trc，其中SID为会话ID，PID为进程ID。
二、使用10046事件跟踪方法除了SQL Trace，Oracle还提供了10046事件跟踪方法。
通过在会话级别启用10046事件跟踪，我们可以获得比SQL Trace更详细的跟踪信息。
启用10046事件跟踪的方法如下：1. 使用ALTER SESSION语句启用10046事件跟踪：ALTER SESSION SET EVENTS '10046 TRACE NAME CONTEXT FOREVER, LEVEL 12';2. 使用DBMS_SYSTEM包启用10046事件跟踪：EXEC DBMS_SYSTEM.SET_EV(12345, 10046, 12, '');启用10046事件跟踪后，Oracle将会将跟踪信息写入跟踪文件中，跟踪文件的位置和命名方式与SQL Trace相同。
SQL语句执行过程详解一条sql，plsql的执行到底是怎样执行的呢？一、SQL语句执行原理：第一步:客户端把语句发给服务器端执行当我们在客户端执行select 语句时,客户端会把这条SQL 语句发送给服务器端,让服务器端的进程来处理这语句。
也就是说,Oracle 客户端是不会做任何的操作,他的主要任务就是把客户端产生的一些SQL 语句发送给服务器端。
虽然在客户端也有一个数据库进程,但是,这个进程的作用跟服务器上的进程作用事不相同的。
服务器上的数据库进程才会对SQL 语句进行相关的处理。
不过,有个问题需要说明,就是客户端的进程跟服务器的进程是一一对应的。
也就是说,在客户端连接上服务器后,在客户端与服务器端都会形成一个进程,客户端上的我们叫做客户端进程;而服务器上的我们叫做服务器进程。
第二步:语句解析当客户端把SQL 语句传送到服务器后,服务器进程会对该语句进行解析。
同理,这个解析的工作,其会做很多小动作。
也是在服务器端所进行的。
虽然这只是一个解析的动作,但是,“”1. 查询高速缓存(library cache)。
服务器进程在接到客户端传送过来的SQL 语句时,不会直接去数据库查询。
而是会先在数据库的高速缓存中去查找,是否存在相同语句的执行计划。
如果在数据高速缓存中,则服务器进程就会直接执行这个SQL 语句,省去后续的工作。
所以,采用高速数据缓存的话,可以提高SQL 语句的查询效率。
一方面是从内存中读取数据要比从硬盘中的数据文件中读取数据效率要高,另一方面,也是因为这个语句解析的原因。
不过这里要注意一点,这个数据缓存跟有些客户端软件的数据缓存是两码事。
有些客户端软件为了提高查询效率,会在应用软件的客户端设置数据缓存。
由于这些数据缓存的存在,可以提高客户端应用软件的查询效率。
但是,若其他人在服务器进行了相关的修改,由于应用软件数据缓存的存在,导致修改的数据不能及时反映到客户端上。
从这也可以看出,应用软件的数据缓存跟数据库服务器的高速数据缓存不是一码事。
oracle_PLSQL快捷键使⽤技巧最近在开发过程中，遇到⼀些⿇烦，就是开发效率问题，有时候其他同事使⽤PLSQL 编程效率明显⾼于⾃⼰，观察了好久，才发现他使⽤PLSQL 已经很长时间了⽽且，他⾃⼰也在其中添加了好多快捷⽅式。
1、登录后默认⾃动选中My Objects默认情况下，PLSQL Developer登录后，Brower⾥会选择All objects，如果你登录的⽤户是dba，要展开tables⽬录，正常情况都需要Wait ⼏秒钟，⽽选择My Objects后响应速率则是以毫秒计算的。
设置⽅法： Tools菜单 --> Brower Filters，会打开Brower Folders的定单窗⼝，把“My Objects”设为默认即可。
Tools菜单－－Brower Folders，中把你经常点的⼏个⽬录（⽐如：Tables Views Seq Functions Procedures）移得靠上⼀点，并加上颜⾊区分，这样你的平均寻表时间会⼤⼤缩短，试试看。
2、记住密码 这是个有争议的功能，因为记住密码会给带来数据安全的问题。
但假如是开发⽤的库，密码甚⾄可以和⽤户名相同，每次输⼊密码实在没什么意义，可以考虑让PLSQL Developer记住密码。
设置⽅法：菜单Tools --> Preferences --> Oracle --> Logon History --> Store With Password 3、双击即显⽰表数据⿏标双击表或者视图时的默认响应实在让我感到失望，因为我最关⼼的是表结构和数据，但是双击后这两件事情都没有发⽣，也许默认响应是⾼⼿们需要的，但对我来说查看数据和表结构是最主要的，其他的我不关⼼。
不过好的是这是可以设置的，你可以给⿏标双击和拖放绑定需要的事件，⽐如：双击编辑数据，拖放显⽰表结构，Yeah！ 设置⽅法：菜单Tools --> Preferences --> Browser，在右侧，为不同的Object Type绑定双击和拖放操作。
优化SQL语句的若干方法1、操作符号：NOT IN操作符此操作是强列推荐不使用的，因为它不能应用表的索引。
推荐方案：用NOT EXISTS 或（外连接+判断为空）方案代替"IS NULL", "<>", "!=", "!>", "!<", "NOT", "NOT IN", "NOT LIKE", "LIKE '%500'"，因为他们不走索引全是表扫描。
NOT IN会多次扫描表，使用EXISTS、NOT EXISTS、IN、LEFT OUTER JOIN来替代，特别是左连接, 而Exists比IN更快，最慢的是NOT操作。
使用in时，在IN后面值的列表中，将出现最频繁的值放在最前面，出现得最少的放在最后面，这样可以减少判断的次数2、注意union和union all的区别。
union比union all多做了一步distinct操作。
能用union all的情况下尽量不用union。
3、查询时尽量不要返回不需要的行、列。
另外在多表连接查询时，尽量改成连接查询，少用子查询。
4、尽量少用视图，它的效率低。
对视图操作比直接对表操作慢,可以用存储过程来代替它。
特别的是不要用视图嵌套,嵌套视图增加了寻找原始资料的难度。
我们看视图的本质：它是存放在服务器上的被优化好了的已经产生了查询规划的SQL。
对单个表检索数据时，不要使用指向多个表的视图，直接从表检索或者仅仅包含这个表的视图上读，否则增加了不必要的开销,查询受到干扰.5、创建合理的索引，对于插入或者修改比较频繁的表，尽量慎用索引。
因为如果表中存在索引，插入和修改时也会引起全表扫描。
索引一般使用于where后经常用作条件的字段上。
6、在表中定义字段或者存储过程、函数中定义参数时，将参数的大小设置为合适即可，勿设置太大。
Oracle六种⽅法查看执⾏计划⽬录：(⼀)六种执⾏计划（1）explain plan for（2）set autotrace on（3）statistics_level=all（4）dbms_xplan.display_cursor获取（5）事件10046 trace跟踪（6）awrsqrpt.sqlOracle提供了6种执⾏计划获取⽅法，各种⽅法侧重点不同。
第⼀种：explain for步骤⼀：explain for 查询sql语句步骤⼆：select * from table(dbms_xplan.display());/*优点：⽆需真正执⾏，快捷⽅便；缺点：1.没有输出相关统计信息，例如产⽣了多少逻辑读，多少次物理读，多少次递归调⽤的情况；2.⽆法判断处理了多少⾏；3.⽆法判断表执⾏了多少次*/第⼆种：set autotrace on步骤⼀：sql> set autotrace on traceonly;步骤⼆：sql>执⾏查询Sql语句步骤三：sql> set autotrace off;/*优点：1.可以输出运⾏时的相关统计信息（产⽣多少逻辑读、多少次递归调⽤、多少次物理读等）；2.虽然要等语句执⾏完才能输出执⾏计划，但是可以有traceonly开关来控制返回结果不打屏输出；缺点：1.必须要等SQL语句执⾏完，才出结果；2.⽆法看到表被访问了多少次；*/第三种：（3）statistics_level=all步骤⼀：ALTER SESSION SET STATISTICS_LEVEL=ALL;步骤⼆：执⾏待分析的SQL步骤三：select * from table(dbms_xplan.display_cursor(null,null,'allstats last'));/*关键字解读：1.starts：SQL执⾏的次数；2.E-Rows：执⾏计划预计返回的⾏数；3.R-Rows：执⾏计划实际返回的⾏数；4.A-Time：每⼀步执⾏的时间(HH:MM:SS.FF)，根据这⼀⾏可知SQL耗时在哪些地⽅；5.Buffers：每⼀步实际执⾏的逻辑读或⼀致性读；6.Reads：物理读；7.OMem：OMem为最优执⾏模式所需的内存评估值，这个数据是由优化器统计数据以及前⼀次执⾏的性能数据估算得出的；8.1Mem：1Mem为one-pass模式所需的内存评估值，当⼯作区⼤⼩⽆法满⾜操作所需的⼤⼩时，需要将部分数据写⼊临时磁盘空间中(如果仅需要写⼊⼀次就可以完成操作，就称⼀次通过，One-Pass;否则为多次通过，Multi-Pass).该列数据为语句最后⼀次执⾏中，单次写磁盘所需要的内存⼤⼩，这个由优化器统计数据以及前⼀次执⾏的性能数据估算得出的ed_Mem：Used-Mem则为当前操作实际执⾏时消耗的内存，括号⾥⾯为(发⽣磁盘交换的次数,1次即为One-Pass,⼤于1次则为Multi_Pass,如果没有使⽤磁盘，则显⽰0)*//*优点：1.可以清晰的从starts得出表被访问多少次；2.可以从E-Rows和A-Rows得到预测的⾏数和真实的⾏数，从⽽可以准确判断Oracle评估是否准确；3.虽然没有准确的输出运⾏时的相关统计信息，但是执⾏计划中的Buffers就是真实的逻辑读的数值；缺点：1.必须要等执⾏完后才能输出结果；2.⽆法控制结果打屏输出，不像autotrace可以设置traceonly保证不输出结果；3.看不出递归调⽤，看不出物理读的数值*/第四种：dbms_xplan.display_cursor获取步骤1：select * from table( dbms_xplan.display_cursor('&sql_id') ); --该⽅法是从共享池得到，如果SQL已被age out出share pool，则查找不到注释：1.还有1种⽅法，select * from table( dbms_xplan.display_awr('&sql_id') ); --该⽅法是从awr性能视图⾥⾯获取2.如果有多个执⾏计划，可⽤以下⽅法查出：select * from table(dbms_xplan.display_cursor('&sql_id',0));select * from table(dbms_xplan.display_cursor('&s ql_id',1));/*优点：1.知道sql_id即可得到执⾏计划，与explain plan for⼀样⽆需执⾏；2.可得到真实的执⾏计划缺点：1.没有输出运⾏的统计相关信息；2.⽆法判断处理了多少⾏；3.⽆法判断表被访问了多少次；*/第五种：事件10046 trace跟踪/*步骤1：alter session set events '10046 trace name context forever,level 12'; --开启追踪步骤2：执⾏sql语句；步骤3：alter session set events '10046 trace name context off'; --关闭追踪步骤4：select tracefile from v$process where addr=(select paddr from v$session where sid=(select sid from v$mystat where rownum<=1)); --找到跟踪后产⽣的⽂件步骤5：tkprof trc⽂件⽣成⽬标⽂件 sys=no sort=prsela,exeela,fchela --格式化命令*/第六种：awrsqrpt.sql/*步骤1：@?/rdbms/admin/awrsqrpt.sql步骤2：选择你要的断点（begin snap和end snap）步骤3：输⼊要查看的sql_id*/例⼦：见：（⼆）如何选择选择时⼀般遵循以下规则：1.如果sql执⾏很长时间才出结果或返回不了结果，⽤⽅法1：explain plan for2.跟踪某条sql最简单的⽅法是⽅法1：explain plan for，其次是⽅法2：set autotrace on3.如果相关查询某个sql多个执⾏计划的情况，只能⽤⽅法4：dbms_xplan.display_cursor或⽅法6：awrsqrpt.sql4.如果sql中含有函数，函数中有含有sql，即存在多层调⽤，想准确分析只能⽤⽅法5：10046追踪5.想法看到真实的执⾏计划，不能⽤⽅法1：explain plan for和⽅法2：set autotrace on6.想要获取表被访问的次数，只能⽤⽅法3：statistics_level = all。
PLSQLDeveloper使⽤技巧、快捷键PLSQL Developer使⽤技巧、快捷键1、类SQL PLUS窗⼝:File->New->Command Window，这个类似于oracle的客户端⼯具sql plus，但⽐它好⽤多了。
2、设置关键字⾃动⼤写:Tools->Preferences->Editor，将Keyword case选择Uppercase。
这样在窗⼝中输⼊sql语句时，关键字会⾃动⼤写，⽽其它都是⼩写。
这样阅读代码⽐较容易，且保持良好得编码风格，同理，在Tools->Preferences->Code Assistant(助⼿)⾥可以设置代码提⽰延迟时间、输⼊⼏个字符时提⽰、数据库对象的⼤写、⼩写，⾸字母⼤写等；3、查看执⾏计划:选中需要分析的SQL语句，然后点击⼯具栏的Explain plan按钮(即执⾏计划)，或者直接按F5；这个主要⽤于分析SQL语句执⾏效率，分析表的结构，便于为sql调优提供直观依据；4、⾃动替换:快捷输⼊SQL语句，例如输⼊s，按下空格，⾃动替换成SELECT；再例如，输⼊sf，按下空格，⾃动替换成SELECT * FROM，⾮常⽅便，节省了⼤量的时间去编写重复的SQL语句。
设置⽅法：菜单Tools–>Preferences–>Editor–>AutoReplace(⾃动替换)–>Edit1)、建⽴⼀个⽂本⽂件shortcuts.txt，并写⼊如下内容：s=SELECT复制代码另存到PL/SQL Developer的安装路径下的~/PlugIns⽬录下2)、Tools–>Preferences–>User Interface–>Editor–>AutoReplace，选中Enable复选框，然后浏览⽂件选中之前创建的shortcuts.txt，点击Apply。
3)、重启PL/SQL Developer，在sql窗⼝中输⼊s+空格，sc+空格做测试。
oracle执行计划怎么看Oracle执行计划怎么看。
Oracle数据库系统是当今世界上应用最广泛的关系型数据库管理系统之一，它的执行计划对于数据库性能的优化和调优起着至关重要的作用。
执行计划是Oracle数据库在执行SQL语句时生成的一种执行策略，它告诉我们数据库是如何执行SQL语句的，通过分析执行计划，我们可以了解SQL语句的执行效率，找到优化的空间，提高数据库的性能。
本文将介绍如何查看Oracle执行计划，以及如何解读执行计划，帮助大家更好地理解和优化SQL语句的执行效率。
一、查看执行计划的方法。
1. 使用EXPLAIN PLAN语句。
在Oracle中，我们可以使用EXPLAIN PLAN语句来获取SQL语句的执行计划。
具体的语法如下：EXPLAIN PLAN FOR。
SQL语句;然后可以使用如下语句来查看执行计划：SELECT FROM TABLE(DBMS_XPLAN.DISPLAY);2. 使用AUTOTRACE。
在SQLPlus或者SQL Developer中，我们可以使用AUTOTRACE功能来查看SQL语句的执行计划。
在SQLPlus中，可以使用如下语句开启AUTOTRACE功能：SET AUTOTRACE ON;然后执行需要查看执行计划的SQL语句即可。
3. 使用SQL Developer。
对于Oracle数据库开发人员来说，SQL Developer是一个非常常用的工具，它提供了直观的图形界面来查看SQL语句的执行计划。
在SQL Developer中，执行SQL语句后，可以通过右键菜单选择“Explain Plan”来查看执行计划。
二、执行计划的解读。
1. 表的访问方式。
在执行计划中，我们可以看到表的访问方式，包括全表扫描、索引扫描、唯一索引扫描等。
全表扫描意味着数据库将会扫描整张表，而索引扫描则表示数据库将会利用索引来快速定位数据，不同的访问方式对于SQL语句的性能影响很大。
Oracle的SQL语句执行效率问题查找与解决方法一、识别占用资源较多的语句的方法（4种方法）1.测试组和最终用户反馈的与反应缓慢有关的问题。
2.利用V_$SQLAREA视图提供了执行的细节。
（执行、读取磁盘和读取缓冲区的次数）•数据列EXECUTIONS：执行次数DISK_READS：读盘次数COMMAND_TYPE：命令类型（3:select,2:insert;6:update;7delete;47:pl/sql程序单元）OPTIMIZER_MODE：优化方式SQL_TEXT：Sql语句SHARABLE_MEM：占用shared pool的内存多少BUFFER_GETS：读取缓冲区的次数•用途1、帮忙找出性能较差的SQL语句2、帮忙找出最高频率的SQL3、帮忙分析是否需要索引或改善联接3.监控当前Oracle的session，如出现时钟的标志，表示此进程中的sql运行时间较长。
4.Trace工具：a)查看数据库服务的初始参数：timed_statistics、user_dump_dest和max_dump_file_sizeb)Step 1: alter session set sql_trace=truec)Step 2: run sql；d)Step 3: alter session set sql_trace=falsee)Step 4:使用“TKPROF”转换跟踪文件f)Parse，解析数量大通常表明需要增加数据库服务器的共享池大小，query或current提取数量大表明如果没有索引，语句可能会运行得更有效，disk提取数量表明索引有可能改进性能，library cache中多于一次的错过表明需要一个更大的共享池大小二、如何管理语句处理和选项•基于成本（Cost Based）和基于规则（Rule Based）两种优化器，简称为CBO 和RBO •Optimizer Mode参数值:Choose：如果存在访问过的任何表的统计数据，则使用基于成本的Optimizer,目标是获得最优的通过量。
如果一些表没有统计数据，则使用估计值。
如果没有可用的统计数据，则将使用基于规则的OptimizerAll_rows：总是使用基于成本的Optimizer，目标是获得最优的通过量First_rows_n：总是使用基于成本的Optimizer，目标是对返回前N行（“n”可以是1，10，100或者1000）获得最优的响应时间First_rows：用于向后兼容。
使用成本与试探性方法的结合，以便快速传递前几行RULE：总是使用基于规则的Optimizer三、使用数据库特性来获得有助于查看性能的处理统计信息（解释计划和AUTOTRACE）No1: Explain PlanA）使用Explain工具需要创建Explain_plan表，这必须先进入相关应用表、视图和索引的所有者的帐户内. (@D:\oracle\ora92\rdbms\admin\utlxplan)B）表结构：STATEMENT_ID：为一条指定的SQL语句确定特定的执行计划名称。
如果在EXPLAN PLAN 语句中没有使用SET STATEMENT_ID，那么此值会被设为NULL。
OPERATION：在计划的某一步骤执行的操作名称，例如：Filters，Index，Table，Marge Joins and Table等。
OPTION：对OPERATION操作的补充，例如：对一个表的操作，OPERATION可能是TABLE ACCESS，但OPTION可能为by ROWID或FULL。
Object_Owner：拥有此database Object的Schema名或Oracle帐户名。
Object_name：Database Object名Object_type：类型，例如：表、视图、索引等等ID：指明某一步骤在执行计划中的位置。
PARENT_ID：指明从某一操作中取得信息的前一个操作。
通过对与ID和PARENT_ID使用Connect By操作，我们可以查询整个执行计划树。
C）EXPLAIN搜索路径解释•全表扫描（Full Table Scans）(无可用索引,大量数据,小表 ,全表扫描hints,HWM(High Water Mark), Rowid扫描)•索引扫描索引唯一扫描（Index Unique Scans）索引范围扫描（Index Range Scans）索引降序范围扫描（Index Range Scans Descending）索引跳跃扫描（Index Skip Scans）全索引扫描（Full Scans）快速全索引扫描（Fast Full Index Scans）索引连接（Index Joins）位图连接（Bitmap Joins）•如何选择访问路径：CBO首先检查WHERE子句中的条件以及FROM子句，确定有哪些访问路径是可用的。
然后CBO使用这个访问路径产生一组可能的执行计划，再通过索引、表的统计信息评估每个计划的成本，最后优化器选择成本最低的一个。
•表的连接方式：Nested Loops会循环外表（驱动表），逐个比对和内表的连接是否符合条件。
在驱动表比较小，内表比较大，而且内外表的连接列有索引的时候比较好。
当SORT_AREA 空间不足的时候，Oracle也会选择使用NL。
基于Cost的Oracle优化器(CBO)会自动选择较小的表做外表。
（优点：嵌套循环连接比其他连接方法有优势,它可以快速地从结果集中提取第一批记录,而不用等待整个结果集完全确定下来。
缺点：如果内部行源表(读取的第二张表（内表）已连接的列上不包含索引,或者索引不是高度可选时, 嵌套循环连接效率是很低的。
如果驱动行源表(从驱动表中提取的记录)非常庞大时,其他的连接方法可能更加有效。
）SORT-merge JOIN，将两表的连接列各自排序然后合并，只能用于连接列相等的情况，适合两表大小相若的情况（在缺乏数据的选择性或者可用的索引时,或者两个源表都过于庞大(超过记录数的5%)时,排序合并连接将比嵌套循环连更加高效。
但是,排列合并连接只能用于等价连接(WHERE D.deptno=E.dejptno,而不是WHERED.deptno>=E.deptno)。
排列合并连接需要临时的内存块,以用于排序(如果SORT_AREA_SIZE设置得太小的话)。
这将导致在临时表空间占用更多的内存和磁盘I/O。
）HASH JOIN在其中一表的连接列上作散列，因此只有另外一个表做排序合并，理论上比SORT JOIN会快些，需要有足够的内存，而且打开了SORT_JOIN_ENABLE参数。
(当缺少有用的索引时，哈希连接比嵌套循环连接更加有效。
哈希连接可能比排序合并连接更快，因为在这种情况下只有一张源表需要排序。
哈希连接也可能比嵌套循环连接更快，因为处理内存中的哈希表比检索B_树索引更加迅速。
和排序合并连接、群集连接一样，哈希连接只能用于等价连接。
和排序合并连接一样，哈希连接使用内存资源，并且当用于排序内存不足时，会增加临时表空间的I/O（这将使这种连接方法速度变得极慢）。
最后，只有基于代价的优化器才可以使用哈希连接。
) 索引连接:No2: AUTOTRACE•set autotrace 使用步骤：1、以system登录2、创建plustrace角色; <your_oracle_home>\sqlplus\admin\plustrce.sql3、向常规用户授予权限：grantplustrace to <user id>4、如果没有plan_table也要创建: <your_oracle_home>\rdbms\admin\utlxplan.sql四、最后，使用计时特性来测量和比较处理时间Set timing onV$session_event应观注一下event这列，这是我们调优的关键一列，下面对常出现的event做以简要的说明：a、buffer busy waits，free buffer waits这两个参数所标识是dbwr是否够用的问题，与IO很大相关的，当v$session_wait中的free buffer wait的条目很小或没有的时侯，说明你的系统的dbwr进程决对够用，不用调整；free buffer wait的条目很多，你的系统感觉起来一定很慢，这时说明你的dbwr已经不够用了，它产生的wio已经成为你的数据库性能的瓶颈，这时的解决办法如下：a.1增加写进程，同时要调整db_block_lru_latches参数示例：修改或添加如下两个参数db_writer_processes=4db_block_lru_latches=8a、2开异步IO，IBM这方面简单得多，hp则麻烦一些，可以与Hp工程师联系。
b、db file sequential read，指的是顺序读，即全表扫描，这也是我们应该尽量减少的部分，解决方法就是使用索引、sql调优，同时可以增大db_file_multiblock_read_count这个参数。
c、db file scattered read,这个参数指的是通过索引来读取，同样可以通过增加db_file_multiblock_read_count这个参数来提高性能。
d、latch free,与栓相关的了，需要专门调节。
e、其他参数可以不特别观注。
本文的目的：1、说一说Oracle的Optimizer及其相关的一些知识。
2、回答一下为什么有时一个表的某个字段明明有索引,当观察一些SQL的执行计划时,发现确不走索引的问题。
3、如果你对FIRST_ROWS、ALL_ROWS这两种模式有疑惑时也可以看一下这篇文章。
开始吧:Oracle在执行一个SQL之前,首先要分析一下语句的执行计划,然后再按执行计划去执行。
分析语句的执行计划的工作是由优化器(Optimizer)来完成的。
不同的情况,一条SQL可能有多种执行计划,但在某一时点,一定只有一种执行计划是最优的,花费时间是最少的。
相信你一定会用Pl/sql Developer、Toad等工具去看一个语句的执行计划,不过你可能对Rule、Choose、First rows、All rows这几项有疑问,因为我当初也是这样的,那时我也疑惑为什么选了以上的不同的项,执行计划就变了?1、优化器的优化方式Oracle的优化器共有两种的优化方式,即基于规则的优化方式(Rule-Based Optimization,简称为RBO)和基于代价的优化方式(Cost-Based Optimization,简称为CBO)。
A、RBO方式：优化器在分析SQL语句时,所遵循的是Oracle内部预定的一些规则。
