㈠ 如何查找Oracle中存在全表扫描的sql语句
1． 对返回的行无任何限定条件，即没有where 子句
2． 未对数据表与任何索引主列相对应的行限定条件
例如：在City-State-Zip列创建了三列复合索引，那么仅对State列限定条件不能使用这个索引，因为State不是索引的主列。
3． 对索引的主列有限定条件，但是在条件表达式里使用以下表达式则会使索引失效，造成全表扫描：
（1）where子句中对字段进行函数、表达式操作，这将导致引擎放弃使用索引而进行全表扫描,
Demo:
where upper(city)='TokYo' 或 City || 'X' like 'TOKYO%',
select id from t where num/2=100 应改为: select id from t where num=100*2
select * from emp where to_char(hire_date,'yyyymmdd')='20080411' (不使用)
select * from emp where hire_date = to_char('20080411','yyyymmdd') (使用)
（2）查询字段is null时索引失效，引起全表扫描。
where City is null 或 ,where City is not null,
解决方法：SQL语法中使用NULL会有很多麻烦，最好索引列都是NOT NULL的；对于is null，可以建立组合索引，nvl(字段,0),对表和索引analyse后，is null查询时可以重新启用索引查找,但是效率还不是值得肯定；is not null 时永远不会使用索引。一般数据量大的表不要用is null查询。
select id from t where num is null
可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：
select id from t where num=0
(3)查询条件中使用了不等于操作符（<>、!=）会限制索引、引起全表扫描
Where city!='TOKYO'.
解决方法：通过把不等于操作符改成or，可以使用索引，避免全表扫描。例如，把column<>’aaa’，改成column<’aaa’ or column>’aaa’，就可以使用索引了。
(4)对索引的主列有限定条件，但是条件使用like操作以及值以‘%’开始或者值是一个赋值变量。例如：
where City like '%YOK%'
where City like: City_bind_Variable xl_rao
select * from emp where name like '%A' (不使用索引)
select * from emp where name like 'A%' (使用索引)
解决办法：首先尽量避免模糊查询，如果因为业务需要一定要使用模糊查询，则至少保证不要使用全模糊查询，对于右模糊查询，即like ‘…%’，是会使用索引的；左模糊like ‘%...’无法直接使用索引，但可以利用reverse + function index 的形式，变化成 like ‘…%’；全模糊是无法优化的，一定要的话考虑用搜索引擎。出于降低数据库服务器的负载考虑，尽可能地减少数据库模糊查询。
4． or语句使用不当会引起全表扫描
原因：where子句中比较的两个条件，一个有索引，一个没索引，使用or则会引起全表扫描。例如：where A=：1 or B=：2，A上有索引，B上没索引，则比较B=：2时会重新开始全表扫描
5．模糊查询效率很低：
原因：like本身效率就比较低，应该尽量避免查询条件使用like；对于like‘%...%’（全模糊）这样的条件，是无法使用索引的，全表扫描自然效率很低；另外，由于匹配算法的关系，模糊查询的字段长度越大，模糊查询效率越低。
解决办法：首先尽量避免模糊查询，如果因为业务需要一定要使用模糊查询，则至少保证不要使用全模糊查询，对于右模糊查询，即like‘…%’，是会使用索引的；左模糊like
‘%...’无法直接使用索引，但可以利用reverse + function index的形式，变化成like‘…%’；全模糊是无法优化的，一定要的话考虑用搜索引擎。出于降低数据库服务器的负载考虑，尽可能地减少数据库模糊查询。
6．查询条件中含有is null的select语句执行慢
原因：Oracle 中，查询字段is null时单索引失效，引起全表扫描。
解决方法：SQL语法中使用NULL会有很多麻烦，最好索引列都是NOT NULL的；对于is null，可以建立组合索引，nvl(字段,0),对表和索引analyse后，is null查询时可以重新启用索引查找,但是效率还不是值得肯定；is not null时永远不会使用索引。一般数据量大的表不要用is null查询。
7.查询条件中使用了不等于操作符（<>、!=）的select语句执行慢
原因：SQL中，不等于操作符会限制索引，引起全表扫描，即使比较的字段上有索引
解决方法：通过把不等于操作符改成or，可以使用索引，避免全表扫描。例如，把column<>’aaa’，改成column<’aaa’or column>’aaa’，就可以使用索引了。
8.使用组合索引，如果查询条件中没有前导列，那么索引不起作用，会引起全表扫描；但是从Oracle9i开始，引入了索引跳跃式扫描的特性，可以允许优化器使用组合索引，即便索引的前导列没有出现在WHERE子句中。例如：create index skip1 on emp5(job,empno); 全索引扫描select count(*) from emp5 where empno=7900; 索引跳跃式扫描select /*+ index(emp5 skip1)*/ count(*) from emp5 where empno=7900;前一种是全表扫描，后一种则会使用组合索引。
9. or语句使用不当会引起全表扫描
原因：where子句中比较的两个条件，一个有索引，一个没索引，使用or则会引起全表扫描。例如：where A=：1 or B=：2，A上有索引，B上没索引，则比较B=：2时会重新开始全表扫描。
10.组合索引，排序时应按照组合索引中各列的顺序进行排序，即使索引中只有一个列是要排序的，否则排序性能会比较差。例如：create index skip1 on emp5(job,empno，date); select job，empno from emp5 where job=’manager’and empno=’10’order by job,empno,date desc;实际上只是查询出符合job=’manager’and empno=’10’条件的记录并按date降序排列，但是写成order by date desc性能较差。
11.Update语句，如果只更改1、2个字段，不要Update全部字段，否则频繁调用会引起明显的性能消耗，同时带来大量日志。
12.对于多张大数据量的表JOIN，要先分页再JOIN，否则逻辑读会很高，性能很差。
13.select count(*) from table；这样不带任何条件的count会引起全表扫描，并且没有任何业务意义，是一定要杜绝的。
14.sql的where条件要绑定变量，比如where column=：1，不要写成where column=‘aaa’，这样会导致每次执行时都会重新分析，浪费CPU和内存资源。
15.不要使用in操作符，这样数据库会进行全表扫描，
推荐方案：在业务密集的SQL当中尽量不采用IN操作符
16.not in 使用not in也不会走索引
推荐方案：用not exists或者（外联结+判断为空）来代替
17.> 及 < 操作符（大于或小于操作符）
大于或小于操作符一般情况下是不用调整的，因为它有索引就会采用索引查找，但有的情况下可以对它进行优化，如一个表有100万记录，一个数值型字段 A，30万记录的A=0，30万记录的A=1，39万记录的A=2，1万记录的A=3。那么执行A>2与A>=3的效果就有很大的区别了，因为A>2时ORACLE会先找出为2的记录索引再进行比较，而A>=3时ORACLE则直接找到=3的记录索引。
18.UNION操作符
UNION在进行表链接后会筛选掉重复的记录，所以在表链接后会对所产生的结果集进行排序运算，删除重复的记录再返回结果。实际大部分应用中是不会产生重复的记录，最常见的是过程表与历史表UNION。如：
select * from gc_dfys
union
select * from ls_jg_dfys
这个SQL在运行时先取出两个表的结果，再用排序空间进行排序删除重复的记录，最后返回结果集，如果表数据量大的话可能会导致用磁盘进行排序。
推荐方案：采用UNION ALL操作符替代UNION，因为UNION ALL操作只是简单的将两个结果合并后就返回。
19.WHERE后面的条件顺序影响
WHERE子句后面的条件顺序对大数据量表的查询会产生直接的影响，如
Select * from zl_yhjbqk where dy_dj = '1K以下' and xh_bz=1
Select * from zl_yhjbqk where xh_bz=1 and dy_dj = '1K以下'
以上两个SQL中dy_dj及xh_bz两个字段都没进行索引，所以执行的时候都是全表扫描，第一条SQL的dy_dj = '1KV以下'条件在记录集内比率为99%，而xh_bz=1的比率只为0.5%，在进行第一条SQL的时候99%条记录都进行dy_dj及xh_bz的比较，而在进行第二条SQL的时候0.5%条记录都进行dy_dj及xh_bz的比较，以此可以得出第二条SQL的CPU占用率明显比第一条低。
20.查询表顺序的影响
在FROM后面的表中的列表顺序会对SQL执行性能影响，在没有索引及ORACLE没有对表进行统计分析的情况下ORACLE会按表出现的顺序进行链接，由此因为表的顺序不对会产生十分耗服务器资源的数据交叉。（注：如果对表进行了统计分析，ORACLE会自动先进小表的链接，再进行大表的链接）
㈡ 不借助第三方工具 怎样查看sql的执行计划
I) 使用Explain Plan,查询PLAN_TABLE;
EXPLAIN PLAN
SET STATEMENT_ID='QUERY1'
FOR
SELECT *
FROM a
WHERE aa=1;
SELECT operation, options, object_name, object_type, ID, parent_id
FROM plan_table
WHERE STATEMENT_ID = 'QUERY1'
ORDER BY ID;
II)SQLPLUS中的SET TRACE 即可看到Execution Plan Statistics
SET AUTOTRACE ON;
㈢ Oracle有没有查询计划缓存
在PL/SQL中把相应SQL语句粘贴到SQL窗口，按F5就能查看相应执行计划。
这个是查询缓存中的执行计划。
select * from v$sql_plan
㈣ 失败原因:执行SQL失败,失败原因:批处理中出现错误: ORA-00911: invalid character
应该是错误输入了全角字符，输入半角字符就行了。
错误信息ORA-00911: invalid character说明了在执行的SQL语句中出现了无效字符，所在SQL语句无法通过语法分析过程导致了错误结果。
可能出现的原因有：错误地输入了全角字符，比如输入了全角逗号。
如果使用C++、Java、C#等编程时，总会习惯在语句最后加分号，而这个符号在SQL中是无效字符。
实际语句和列类型不匹配，比如将数值列赋值为字符串。
与display函数不同，display_cursor显示的为真实的执行计划。
对于format参数，使用与display函数的各个值，同样适用于display_cursor函数。
当statistics_level为all或使用gather_plan_statistics提示可以获得执行时的统计信息。
根据真实与预估的统计信息可以初步判断SQL效率低下的原因，如统计信息的准确性、主要的开销位于那些步骤等。
看你的sql语句最后是否有分号，有的话去掉就行 看你Oracle服务器端字符集是否和Oracle客户端字符集匹配。
查询oracle server端的字符集：SQL>select userenv(‘language’) from al。
查询oracle client端的字符集。在windows平台下，就是注册表里面相应OracleHome的NLS_LANG。
还可以在dos窗口里面自己设置，比如: set nls_lang=AMERICAN_AMERICA.ZHS16GBK。
㈤ 怎么使用plsql查看执行计划
一.在线查看执行计划表
如果PLAN_TABLE表不存在，执行$ORACLE_HOME/rdbms/admin/utlxplan.sql创建plan_table表。
1.explain plan
for
select * from ......
2.select * from table(DBMS_XPLAN.Display);
二.使用oracle第三方工具：
plsql developer(F5)
Toad (Ctrl+E)
三.使用SQL*PLUS：
如果PLAN_TABLE表不存在，执行$ORACLE_HOME/rdbms/admin/utlxplan.sql创建plan_table表。
如果PLUSTRACE角色不存在，执行
$ORACLE_HOME/sqlplus/admin/plustrce.sql
1.sqlplus / as sysdba
set autotrace on;
关于Autotrace几个常用选项的说明:
SET AUTOTRACE OFF ---------------- 不生成AUTOTRACE 报告，这是缺省模式
SET AUTOTRACE ON EXPLAIN ------ AUTOTRACE只显示优化器执行路径报告
SET AUTOTRACE ON STATISTICS -- 只显示执行统计信息
SET AUTOTRACE ON ----------------- 包含执行计划和统计信息
SET AUTOTRACE TRACEONLY ------ 同set autotrace on，但是不显示查询
2.执行sql
四.sql trace
1.alter session set sql_trace=true;
2.执行sql
3.alter session set sql_trace=false;
4.查看相应的sql trace文件。
五.诊断事件(10046)
1.alter session set events '10046 trace name context forever,level 12';
2.执行sql
3.alter session set events '10046 trace name context off';
3.查看相应的sql trace文件。
可利用TKPROF工具查看跟踪文件
TKPROF是一个用于分析oracle跟踪文件并且产生一个更加清晰合理的输出结果的可执行工具。如果一个系统的执行效率比较低，一个比较好的方法是跟踪用户的会话并且使用TKPROF工具的排序功能格式化输出，从而找出有问题的SQL语句。
TKPROF命令后面的选项及输出文件各个列的含义在这里不做详细的介绍。google一下就会有很多资料。
下面简单描述一下TKPROF工具的使用步骤：
1、在session级别设置sql_trace=true
sys@ORCL>alter session set sql_trace=true;
Session altered.
如果要在pl/sql中对session级别设置true，可以使用dbms_system这个包：
sys@ORCL> exec dbms_system.set_sql_trace_in_session(sid,serial#,true);
2、指定一下生成的trace文件的名字，便于查找：
sys@ORCL>alter session set trace file_identifier='yourname';
3、执行SQL语句。
4、利用TKPROF工具格式化输出的trace 文件：
[oracle@q1test01~] $tkprof/oracle/admin/orcl/ump/orcl_ora_10266_yourname.trc/oracle/yourname.txtexplain=user/pwdaggregate=yessys=nowaits=yessort=fchela
5、查看生成的文件再设置sql_trace=false：
sys@ORCL>alter session set sql_trace=false;
㈥ 获取SQL执行计划的常见几种方法
1. 预估执行计划 - Explain Plan
Explain plan以SQL语句作为输入，得到这条SQL语句的执行计划，并将执行计划输出存储到计划表中。
首先，在你要执行的SQL语句前加explain plan for，此时将生成的执行计划存储到计划表中，语句如下：
explain plan for SQL语句
然后，在计划表中查询刚刚生成的执行计划，语句如下：
select * from table(dbms_xplan.display);
注意：Explain plan只生成执行计划，并不会真正执行SQL语句，因此产生的执行计划有可能不准，因为：
1）当前的环境可能和执行计划生成时的环境不同；
2）不会考虑绑定变量的数据类型；
3）不进行变量窥视。
2. 查询内存中缓存的执行计划 （dbms_xplan.display_cursor）
如果你想获取正在执行的或刚执行结束的SQL语句真实的执行计划（即获取library cache中的执行计划），可以到动态性能视图里查询。方法如下：
1）获取SQL语句的游标
游标分为父游标和子游标，父游标由sql_id(或联合address和hash_value)字段表示，子游标由child_number字段表示。
如果SQL语句正在运行，可以从v$session中获得它的游标信息，如：
select status, sql_id, sql_child_number from v$session where status='ACTIVE' and ....
如果知道SQL语句包含某些关键字，可以从v$sql视图中获得它的游标信息，如：
select sql_id, child_number, sql_text from v$sql where sql_text like '%关键字%‘
2）获取库缓存中的执行计划
为了获取缓存库中的执行计划，可以直接查询动态性能视图v$sql_plan和v$sql_plan_statistics_all等，但更方便的方法是以sql_id和子游标为参数，执行如下语句：
select * from table(dbms_xplan.display_cursor('sql_id',child_number));
3）获取前一次的执行计划：
set serveroutput off
select * from table(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST'));
3. 查询历史执行计划（dbms_xplan.display_awr）
AWR会定时把动态性能视图中的执行计划保存到dba_hist_sql_plan视图中，如果你想要查看历史执行计划，可以采用如下方法查询：
select * from table(dbms_xplan.display_awr('sql_id');
4. 在用sqlplus做SQL开发是（Autotrace）
set autotrace是sqlplus工具的一个功能，只能在通过sqlplus连接的session中使用，它非常适合在开发时测试SQL语句的性能，有以下几种参数可供选择：
SET AUTOTRACE OFF ---------------- 不显示执行计划和统计信息，这是缺省模式
SET AUTOTRACE ON EXPLAIN ------ 只显示优化器执行计划
SET AUTOTRACE ON STATISTICS -- 只显示统计信息
SET AUTOTRACE ON ----------------- 执行计划和统计信息同时显示
SET AUTOTRACE TRACEONLY ------ 不真正执行，只显示预期的执行计划，同explain plan
5. 生成Trace文件查询详细的执行计划 （SQL_Trace, 10046）
SQL_TRACE作为初始化参数可以在实例级别启用，也可以只在会话级别启用，在实例级别启用SQL_TRACE会导致所有进程的活动被跟踪，包括后台进程及所有用户进程，这通常会导致比较严重的性能问题，所以在一般情况下，我们使用sql_trace跟踪当前进程，方法如下：
SQL>alter session set sql_trace=true;
...被跟踪的SQL语句...
SQL>alter session set sql_trace=false;
如果要跟踪其它进程，可以通过Oracle提供的系统包DBMS_SYSTEM. SET_SQL_TRACE_IN_SESSION来实现，例如：
SQL> exec dbms_system.set_sql_trace_in_session(sid,serial#,true) --开始跟踪
SQL> exec dbms_system.set_sql_trace_in_session(sid,serial#,false) --结束跟踪
生成trace文件后，再用tkprof 工具将sql trace 生成的跟踪文件转换成易读的格式，语法如下：
tkprof inputfile outputfile
10046事件是SQL_TRACE的一个升级版，它也是追踪会话，生成Trace文件，只是它里面的内容更详细，
㈦ 如何在执行sql后看到execution plan 的结果
在SQL Server中，我们通常将脚本加载到 Management Studio 查询编辑器后，通过单击查询编辑器工具栏上的“显示估计的执行计划”或“包括实际的执行计划”按钮，可以选择是显示估计的执行计划还是显示实际的执行计划。如果单击“显示估计的执行计划”，则将分析该脚本并生成估计的执行计划。如果单击“包括实际的执行计划”，则必须在生成执行计划之前执行该脚本。分析或执行脚本之后，请单击“执行计划”选项卡以查看执行计划输出的图形表示形式。你可以参考微软官方文档：https://technet.microsoft.com/zh-cn/library/ms178071(v=sql.105).aspx
㈧ 这句带有大于，小于号的查询条件的SQL是全表查询吗怎么提高它的查询效率
带where条件了，不是全表查询，把后面的问号替换成具体的条件，另外，将查询*替换为具体要查的字段，如果表有索引，并且条件字段也含有索引字段，最好走索引
晕，不知道你表的索引、主键情况，也不知道你where条件后面怎么写的，怎么可能知道你的执行计划呢？
看sql语句的执行效率，可以在plsql的执行计划窗口（explain plan window）查看，根据执行计划再来调整你的sql语句