主要从SQL执行信息（v$sql,gv$sql...)和SQL执行计划(v$sql_plan,gv$sql_plan,v$sql_plan_statistics_all...)的特点上来讨论，比如：
1.OLTP环境下，v$sql上executions>1000的，单次elapsed_time>3s,就认为可能SQL属于高耗SQL，需要关注。。。
2.执行计划有笛卡尔积运算的，需要关注。。。
3.OLTP环境下，SORT MERGE JOIN的需要关注。。。
4.谓词出现显示函数运算或自动函数索引或数学运算，运算在索引列上的需要关注。。。
5.执行计划有FILTER多子操作，且父操作card估算超过1000的。。。需要关注
1. 索引建立的不合理。
2.N久没有收集统计信息。
3.一个表的名字出现多次，造成对表的多次 scan 。
btree index 出现bitmap conversion
1. SQL文本比较长，一眼看上去比较复杂
2. 没有恰当地使用INDEX
3. （老版中）统计信息收集不及时，与实际差异较大
4. 涉及的表没有进行有效的段空间维护，使得数据实际小，而高水位很高
5. 对其调整是要用到执行计划
6. 复杂的SQL，DBA会做等价改写
1.SQL里面嵌入自定义函数反复执行。
2.动态SQL使用硬解析，没有使用绑定变量。
1：同一个表关联了多次，看看是否可能消除不必要的连接。有的时候是因为使用了视图所导致的，这点我一般会看一下。
2：过多层的NL。要看看数据返回量与优化器的评估量之间的差别。
1、统计信息没问题时，且cost >100,0000，可能业务逻辑有问题， 需要重视；
2、cost < 1000 且 executions > 60s 的， 可能执行计划有问题， 需要重视；
3、SQL 执行计划包括 ‘PARTITION RANGE ALL’ 没加分区条件的， 需要重视；【博客：http://blog.itpub.net/28602568/viewspace-1250423/】
4、一个SQL的执行计划出现了5次全扫，可能遗漏可能加的索引条件，需要重视；
5、执行计划出现(‘MERGE JOIN CARTESIAN‘,‘FILTER‘)，可能情况（统计信息问题、少关联条件
原文地址：http://rscpass.blog.51cto.com/771159/1612763
