1、直接File->New->Explain Plan Window,在窗口中执行sql可以查看计划结果。其中,Cost表示cpu的消耗,单位为n%,Cardinality表示执行的行数,等价Rows。
2、先执行 EXPLAIN PLAN FOR select from tableA where paraA=1,再 select from table(DBMS_XPLANDISPLAY)便可以看到oracle的执行计划了,看到的结果和1中的一样,所以使用工具的时候推荐使用1方法。
注意:PL/SQL Dev工具的Command window中不支持set autotrance on的命令。还有使用工具方法查看计划看到的信息不全,有些时候我们需要sqlplus的支持。
二、通过sqlplus
1.最简单的办法
Sql> set autotrace on
Sql> select from dual;
执行完语句后,会显示explain plan 与 统计信息。
这个语句的优点就是它的缺点,这样在用该方法查看执行时间较长的sql语句时,需要等待该语句执行成功后,才返回执行计划,使优化的周期大大增长。如果不想执行语句而只是想得到执行计划可以采用:
Sql> set autotrace traceonly
一在线查看执行计划表
如果PLAN_TABLE表不存在,执行$ORACLE_HOME/rdbms/admin/utlxplansql创建plan_table表。
1explain plan
for
select from
2select from table(DBMS_XPLANDisplay);
二使用oracle第三方工具:
plsql developer(F5)
Toad (Ctrl+E)
三使用SQLPLUS:
如果PLAN_TABLE表不存在,执行$ORACLE_HOME/rdbms/admin/utlxplansql创建plan_table表。
如果PLUSTRACE角色不存在,执行
$ORACLE_HOME/sqlplus/admin/plustrcesql
1sqlplus / 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
1alter session set sql_trace=true;
2执行sql
3alter session set sql_trace=false;
4查看相应的sql trace文件。
五诊断事件(10046)
1alter session set events '10046 trace name context forever,level 12';
2执行sql
3alter 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_systemset_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/udump/orcl_ora_10266_yournametrc/oracle/yournametxtexplain=user/pwdaggregate=yessys=nowaits=yessort=fchela
5、查看生成的文件再设置sql_trace=false:
sys@ORCL>alter session set sql_trace=false;
看执行计划的时候,从第一行开始向右下看,一直到最右边。如果有并列的,那么先上再下。如果没并列,右边的先执行。
这是一个简单的SQL的执行计划,这个执行计划告诉我们,id=2的最先执行,然后是id=3的,然后执行id=1的。
首先对test1进行一次全表扫描,这一步返回rows=2,CPU的消耗为3。接下来对test进行一次全表扫描,这一次返回的rows为1,CPU的消耗为2。接下来对这两个结果进行一次哈希连接(hash join),返回rows=1,这里的CPU消耗为6,但是需要注意,这次是我的语句赶寸了,6=2X3,但是哈希连接需要的CPU COST绝对不会恰恰是之前执行的 *** 作的CPU COST之积,特别说明一下。至此,我们的oracle对这个语句的执行计划结束。
这个执行计划是怎么得到的?既然是计划,那么绝对不是把这个语句先执行一遍,然后把这个计算出来,那样的话这个执行计划就成了事后诸葛亮了。这个执行计划是oracle根据统计信息得到的。那么这个执行计划就有可能不准,请大家看看我的语句以及执行出来的结果:
SELECT ASER_ID, BOWNER FROM TEST A, TEST1 B WHERE AAREA_ID = BOWNER;结果如图:
怎么样?绝对不是6行那么点点东西吧?这个表的统计信息看来非常非常旧了。于是我对两个表重新进行统计:
ANALYZE TABLE TEST COMPUTE STATISTICS;
ANALYZE TABLE TEST1 COMPUTE STATISTICS;
然后再看看执行计划:
肿么样,这样就不是那么小了吧?test有12M行的返回。test1的owner字段只有两条记录:911和290。那么对应的test中area_id=290/911的有多少条记录呢?count一下:8485760,那么为什么是12M行呢?因为是全表扫描:
SELECT COUNT()/1024/1024 FROM TEST;
结果就是12
现在可以总结一下了:执行计划的准确性(主要指数据返回,数据量大小)由统计信息的准确性决定。
检测mysql中sql语句的效率的方法
1、通过查询日志
(1)、Windows下开启MySQL慢查询
MySQL在Windows系统中的配置文件一般是是myini找到[mysqld]下面加上
代码如下
log-slow-queries = F:/MySQL/log/mysqlslowquery。log
long_query_time = 2
(2)、Linux下启用MySQL慢查询
MySQL在Windows系统中的配置文件一般是是mycnf找到[mysqld]下面加上
代码如下
log-slow-queries=/data/mysqldata/slowquery。log
long_query_time=2
说明
log-slow-queries = F:/MySQL/log/mysqlslowquery。
为慢查询日志存放的位置,一般这个目录要有MySQL的运行帐号的可写权限,一般都将这个目录设置为MySQL的数据存放目录;
long_query_time=2中的2表示查询超过两秒才记录;
2show processlist 命令
SHOW PROCESSLIST显示哪些线程正在运行。您也可以使用mysqladmin processlist语句得到此信息。
各列的含义和用途:
ID列
一个标识,你要kill一个语句的时候很有用,用命令杀掉此查询 //mysqladmin kill 进程号。
user列
显示单前用户,如果不是root,这个命令就只显示你权限范围内的sql语句。
host列
显示这个语句是从哪个ip的哪个端口上发出的。用于追踪出问题语句的用户。
db列
显示这个进程目前连接的是哪个数据库。
command列
显示当前连接的执行的命令,一般就是休眠(sleep),查询(query),连接(connect)。
time列
此这个状态持续的时间,单位是秒。
state列
显示使用当前连接的sql语句的状态,很重要的列,后续会有所有的状态的描述,请注意,state只是语句执行中的某一个状态,一个 sql语句,以查询为例,可能需要经过copying to tmp table,Sorting result,Sending data等状态才可以完成
info列
显示这个sql语句,因为长度有限,所以长的sql语句就显示不全,但是一个判断问题语句的重要依据。
这个命令中最关键的就是state列,mysql列出的状态主要有以下几种:
Checking table
正在检查数据表(这是自动的)。
Closing tables
正在将表中修改的数据刷新到磁盘中,同时正在关闭已经用完的表。这是一个很快的 *** 作,如果不是这样的话,就应该确认磁盘空间是否已经满了或者磁盘是否正处于重负中。
Connect Out
复制从服务器正在连接主服务器。
Copying to tmp table on disk
由于临时结果集大于tmp_table_size,正在将临时表从内存存储转为磁盘存储以此节省内存。
Creating tmp table
正在创建临时表以存放部分查询结果。
deleting from main table
服务器正在执行多表删除中的第一部分,刚删除第一个表。
deleting from reference tables
服务器正在执行多表删除中的第二部分,正在删除其他表的记录。
Flushing tables
正在执行FLUSH TABLES,等待其他线程关闭数据表。
Killed
发送了一个kill请求给某线程,那么这个线程将会检查kill标志位,同时会放弃下一个kill请求。MySQL会在每次的主循环中检查kill标志位,不过有些情况下该线程可能会过一小段才能死掉。如果该线程程被其他线程锁住了,那么kill请求会在锁释放时马上生效。
Locked
被其他查询锁住了。
Sending data
正在处理SELECT查询的记录,同时正在把结果发送给客户端。
Sorting for group
正在为GROUP BY做排序。
Sorting for order
正在为ORDER BY做排序。
Opening tables
这个过程应该会很快,除非受到其他因素的干扰。例如,在执ALTER TABLE或LOCK TABLE语句行完以前,数据表无法被其他线程打开。正尝试打开一个表。
Removing duplicates
正在执行一个SELECT DISTINCT方式的查询,但是MySQL无法在前一个阶段优化掉那些重复的记录。因此,MySQL需要再次去掉重复的记录,然后再把结果发送给客户端。
Reopen table
获得了对一个表的锁,但是必须在表结构修改之后才能获得这个锁。已经释放锁,关闭数据表,正尝试重新打开数据表。
Repair by sorting
修复指令正在排序以创建索引。
Repair with keycache
修复指令正在利用索引缓存一个一个地创建新索引。它会比Repair by sorting慢些。
Searching rows for update
正在讲符合条件的记录找出来以备更新。它必须在UPDATE要修改相关的记录之前就完成了。
Sleeping
正在等待客户端发送新请求
System lock
正在等待取得一个外部的系统锁。如果当前没有运行多个mysqld服务器同时请求同一个表,那么可以通过增加--skip-external-locking参数来禁止外部系统锁。
Upgrading lock
INSERT DELAYED正在尝试取得一个锁表以插入新记录。
Updating
正在搜索匹配的记录,并且修改它们。
User Lock
正在等待GET_LOCK()。
Waiting for tables
该线程得到通知,数据表结构已经被修改了,需要重新打开数据表以取得新的结构。然后,为了能的重新打开数据表,必须等到所有其他线程关闭这个表。以下几种情况下会产生这个通知:FLUSH TABLES tbl_name, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE,或OPTIMIZE TABLE。
waiting for handler insert
INSERT DELAYED已经处理完了所有待处理的插入 *** 作,正在等待新的请求。
大部分状态对应很快的 *** 作,只要有一个线程保持同一个状态好几秒钟,那么可能是有问题发生了,需要检查一下。
还有其他的状态没在上面中列出来,不过它们大部分只是在查看服务器是否有存在错误是才用得着。
1、 查看最近执行的SQL语句
select /recentsql/sSQL_ID,sCHILD_NUMBER,sHASH_VALUE,sADDRESS,sEXECUTIONS,sSQL_TEXT
from v$sql s
where sPARSING_USER_ID = (
select uuser_id from all_users u
where uusername = 'YH_TEST'
) and sCOMMAND_TYPE in (2 ,3, 6,7 ,189)
and upper(sSQL_TEXT) not like upper( '%recentsql%')
2、使用dbms_xplandisplay_cursor查看执行计划,它的用法见笔记 《dbms_xplandisplay_cursor的用法》,
注意了:若dbms_xplandisplay_cursor要以ALLSTATS LAST格式输出的话,/+gather_plan_statistics/这个提示信息放到查询语句中是必须的。
select /+gather_plan_statistics/ /plan_statistics1/ name ,salary from test where name = 't1' ;
打开PL/SQL Developer软件,请确保plsql能够成功连接到一个oracle数据库。
在PL/SQL Developer中写好一段SQL代码,按F5,或者点击“执行执行计划”图标,PL/SQL Developer会自动打开执行计划窗口,显示该SQL的执行计划。
可以看到窗口上方是sql语句,下方显示执行计划表格。表格的列主要包含描述、用户、对象、成本花费、IO开销等,表格,当然表格列还可以自定义。表格的行包含了查询逻辑的执行顺序和各个步骤信息。
执行计划表格内容的执行顺序是:按照从左至右,从上至下的步骤执行,具体是指执行计划按照层次逐步缩进,从左至右看,缩进最多的那一步最先执行,如果缩进量相同,则按照从上而下的方法判断执行顺序。
通过查看执行计划表格的cost列,即成本花费能够知道哪个步骤花费的成本高,通过查看执行计划表格的行中的objectname列,能够知道是否使用到表中的索引。
以上就是关于oracle中的sql执行计划怎么看全部的内容,包括:oracle中的sql执行计划怎么看、怎么使用plsql查看执行计划、sql manager 如何查看执行计划等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)