转自:http://blog.chinaunix.net/uid-21187846-id-3022916.htmlhtml
若是要分析某条SQL的性能问题,一般咱们要先看SQL的执行计划,看看SQL的每一步执行是否存在问题。 若是一条SQL平时执行的好好的,却有一天忽然性能不好,若是排除了系统资源和阻塞的缘由,那么基本能够判定是执行计划出了问题。看懂执行计划也就成了SQL优化的先决条件。这里的SQL优化指的是SQL性能问题的定位,定位后就能够解决问题。web
设置autotrace(非通用)sql
序号工具 |
命令oop |
解释性能 |
1优化 |
SET AUTOTRACE OFFui |
此为默认值,即关闭Autotrace spa |
2.net |
SET AUTOTRACE ON EXPLAIN |
只显示执行计划 |
3 |
SET AUTOTRACE ON STATISTICS |
只显示执行的统计信息 |
4 |
SET AUTOTRACE ON |
包含2,3两项内容 |
5 |
SET AUTOTRACE TRACEONLY |
与ON类似,但不显示语句的执行结果 |
EXPLAIN PLAN FOR sql语句; SELECT plan_table_output FROM TABLE(DBMS_XPLAN.DISPLAY('PLAN_TABLE')); 或者select * from table(dbms_xplan.display);
Cardinality值表示CBO预期从一个行源(row source)返回的记录数,这个行源多是一个表,一个索引,也多是一个子查询。 在Oracle 9i中的执行计划中,Cardinality缩写成Card。 在10g中,Card值被rows替换。
Cardinality的值对于CBO作出正确的执行计划来讲相当重要。 若是CBO得到的Cardinality值不够准确(一般是没有作分析或者分析数据过旧形成),在执行计划成本计算上就会出现误差,从而致使CBO错误的制定出执行计划。
对于多表查询,CBO使用每一个关联表返回的行数(Cardinality)决定用什么样的访问方式来作表关联(如Nested loops Join 或 hash Join)。
多表链接的三种方式详解 HASH JOIN /MERGE JOIN/ NESTED LOOP
http://blog.csdn.net/tianlesoftware/archive/2010/08/20/5826546.aspx
Oracle SQL的硬解析和软解析
http://blog.csdn.net/tianlesoftware/archive/2010/04/08/5458896.aspx
示例:
SQL> SET AUTOTRACE TRACEONLY; -- 只显示执行计划,不显示结果集
SQL> select * from scott.emp a,scott.emp b where a.empno=b.mgr;
在Toad 里面,很清楚的显示了执行的顺序。 可是若是在SQLPLUS里面就不是那么直接。 但咱们也能够判断:通常按缩进长度来判断,缩进最大的最早执行,若是有2行缩进同样,那么就先执行上面的。