性能问题的定位

尽可能从小范围分析问题

SQL层：如果能够定位到SQL，就不要从会话层面分析。

执行计划、10053、10046

会话层：如果能够定位到会话，就不要从系统层面分析。

v$session、v$sesstat、v$session_wait、v$sql、v$lock、sql_trace

系统层：如果无法定位任何性能问题，从系统层面入手。

AWR（8i时叫做statspack）、OS tools（top、iostat…）

优化器无法理解业务逻辑

不要迷恋优化器，优化器无法理解SQL的业务逻辑。

例如可能在业务上同样效果的两条SQL，执行的效率完全不同。

环境搭建：

  1. create table mytable(
  2.     id int,
  3.     value int
  4. );
  5. insert into mytable values(1,10);
  6. insert into mytable values(2,15);
  7. insert into mytable values(3,20);

SQL1:

select t1.id,t1.value,sum(t2.value)
from mytable t1
join mytable t2
    on t2.id <= t1.id
group by t1.id,t1.value
order by t1.id

SQL2:

select id,value, sum(value) over (order by id) from mytable;

两条SQL都是对前n个人分数汇总，但是两个SQL的执行效率完全不同：SQL1会有2次表扫描，14个一致性读；SQL2只有1次表扫描，7个一致性读。

这两条SQL是开发人员在业务层面的高效改写，CBO并不能将SQL1转换成SQL2。