全面的Oracle SQL优化剖析，希望各位大神前来讨论交流

我晕死。。。

一般来说，SQL优化是让SQL运行得更快，使SQL 更快的方式有很多，比如提高索引的使用效率，或者并行查询。

T = S / V
执行效率或者一般说的执行时间，是和完成一次SQL所需要访问的资源总量（S）成正比以及单位时间内能够访问的资源量（V）成反比，S越大，效率越低，V越大效率越高。 比如通过并行查询，则可以提升单位时间内访问的资源量。
当然，这仅仅是从执行时间上考虑，SQL优化肯定不仅仅是执行时间降低，应该是资源使用与执行时间降低之间寻求一种平衡，否则，盲目并行，可能提升不了效率，反而让系统资源消耗殆尽。
总的来说，SQL优化的本质就是：
1、缩短响应时间；
2、提升系统吞吐量；
3、提升系统负载能力。
要使用多种手段，在提升系统吞吐量和增加系统负载能力，提高单个SQL效率之间寻求一种平衡。就是要尽量减少一条SQL需要访问的资源总量，比如走索引更好，那么不要使用全表扫描。

优化Road Map

制定SQL优化目标
获取待优化SQL、制定优化目标：从AWR、ASH、ORA工具等主动发现有问题的SQL、用户报告有性能问题DBA介入等，通过对SQL的执行情况进行了解，先初步制定SQL的优化目标。
检查执行计划
explain工具、sql*plus autotrace、dbms_xplan、10046、10053、awrsqrpt.sql等。 执行计划是我们进行SQL优化的核心内容，无计划，不优化。看执行计划有一些技巧，也有很多方式，各种方式之间是有区别的。
检查统计信息
ORACLE使用DBMS_STATS包对统计信息进行管理，涉及系统统计信息、表、列、索引、分区等对象的统计信息，统计信息是SQL能够使用正确执行计划的保证。我们知道，ORACLE CBO优化器是利用统计信息来判断正确的执行路径，JOIN方式的，因此，准确的统计信息是产生正确执行计划的首要条件。
可以从这个图看出，一条SQL产生执行计划需要经过哪些步骤，在我看来：
1、正确的查询转换；
2、准确的统计信息，是产生正确执行计划的重要保证。
当然，还有BUG，或优化器限制等也会导致SQL效率低下，无法产生正确的执行计划。

=，= 写错一个字了，大家多多包涵。。。。。没检查啊锅啊。。。。。╮(╯▽╰)╭

检查高效访问结构
重要的访问结构，诸如索引、分区等能够快速提高SQL执行效率。表存储的数据本身，如碎片过多、数据倾斜严重、数据存储离散度大，也会影响效率。
检查影响优化器的参数
optimizer_mode、optimizer_index_cost_adj、optimizer_dynamic sampling、_optimizer_mjc_enabled、_optimizer_cost_based_transformation、hash_join_enable等对SQL执行计划影响较大。比如有时候我们通过禁用_optimizer_mjc_enabled 参数，让执行计划不要使用笛卡尔积来提升效率，因为这个参数开启有很多问题，所以一般生产库都要求禁用。
还有什么能够影响执行计划呢？对，new features,每个版本的new features，引入的目的都是好的，但是实际使用中，可能触发BUG。比如11g的ACS(自适应游标共享）、automatic serial direct path（自动串行直接路径读）、extended statistics、SQL query result cache等。有的新特性会导致问题，所以需要谨慎使用。
比如11g adaptive cursor sharing,自适应游标共享，它的引入是为了解决使用绑定变量与数据倾斜值，要产生多样性执行计划。因为绑定变量是为了共享执行计划，但是数据倾斜了，有的值要求走索引，有的值要求走全表，这样与使用绑定变量就产生了矛盾。以前是通过cursor_sharing=similar这样的设置可以解决，但是有很多BUG，会产生version count过高的问题，或者我们对不同的值（如果值很少），可以写多条SQL来解决，这都不是好的方案，11g acs引入就是为了解决这些问题，让这些东西交给oracle来做。但是事与愿违，以后你们遇到执行计划一会变一下，有快有慢，首先可以检查acs有没有关闭。
alter system set “_optimizer_extended_cursor_sharing_rel”=’NONE';
SQL语句编写问题
SQL语句结构复杂、使用了不合理的语法，比如UNION代替UNION ALL都可能导致性能低下。 并不是说ORACLE优化器很强大了，我们就可以随便写SQL了，那是不正确的。SQL是一门编程语言，它能够执行的快，是有一些普遍的规则的，遵循这种编程语言特性，简化语句，才能写出好的程序。SQL语句编写出了问题，我们就需要改写，就需要调整业务，改涉及等。
SQL优化器限制导致的执行计划差
这个很重要，统计信息准确，SQL也不复杂，索引也有。。。都满足，为什么我的SQL还是差，那么得考虑优化器限制因素了。这里说1点常见的执行计划限制，当semi join与or连用的时候（也就是exists(subquery) or ...或者in (subquery) or...，如果执行计划中因为OR导致有FILTER操作符，就得注意了，可能慢的因素就和OR有关。这时候我们得改写SQL，当然改写为UNION或UNION ALL了。
OK，以上全部检查完毕，我的系统还是很差，功能还是很慢，或者已经无法从SQL本身进行调整提升性能了，那咋办？优化设计，这是终极方法。有些东西不优化设计是无法解决的，比如业务高峰期跑了一堆SQL，CPU已经很吃紧，又不给增加，突然上线一个耗资源的业务，其他SQL已无法调整。那只能优化设计，比如有些耗资源的业务可以换时间段执行等。
以上几点，是我们进行优化需要考虑的地方，可以逐步检查。当然，80%到90%的纯SQL性能调整，我们通过建立索引，收集正确统计信息，改写避免优化器限制，已经能够解决了。

SQL优化案例
看第一个获取待优化的SQL.......如果主动优化，一般从AWR、ASH等里面找到性能差的SQL，然后优化之。


上面的案例，占CPU 72%的SQL来自于同一模块，第一行是存储过程，通过下面绿色框住的SQL与第一行比较，主要通过EXECUTION，基本判断下面的绿色框住的SQL就是那个存储过程中的。也可以和业务确认下，OK，这些SQL的执行频次很高，因为是营销业务，如果要优化，就得搞定这些SQL。
这些SQL，单条SQL的buffer gets也就1000多点，效率还是很高的，但是因为执行的太过于频繁，所以资源消耗极大，因此，得检查下，能不能更优呢？

以第1条SQL：58q183atbusat为例：
SELECT B.ACT_ID,
B.ACT_NAME,
B.TASK_ID,
B.MKT_DICTION,
B.CUST_GROUP_ID,
NVL(B.ATTEST_FLAG, 'N'),
NVL(B.DOUWIN_FLAG, 'N'),
B.CHN_DESC,
NVL(B.SIGN_FLAG, 'N'),
B.MAX_EXECUTE_NUM
FROM (SELECT DISTINCT (ACT_ID)
FROM MK_RULECHN_REL
WHERE CHN_STATUS = '04'
AND CHN_TYPE = :B1) A,
TABLE(CAST(:B2 AS TYPE_MK_ACTIONINFO_TABLE)) B
WHERE A.ACT_ID = B.ACT_ID
SQL其实很简单，一个查询构建的A表，一个TABLE函数构建的B表关联..... 不知道大家对这个TABLE函数熟悉不熟悉？也就是将一个集合转成表，是PL/SQL里的东西。
那个collection部分就是TABLE函数，下面的表走了全表扫描：

PS：全盘扫描导致性能问题，检查统计信息、索引等都正确，那么问题在哪儿? 0,0
按步骤检查，发现不了问题，但是知道，可能是因为HASH JOIN导致全表扫描的问题，是否走NESTED LOOPS+INDEX更好，很显然，要检查TABLE函数大概返回多少行。
经过确认，最多也就返回200-300行，最终结果集也是几百行而已。
那么猜测，问题就在于TABLE函数，走了HASH JOIN，上面的执行计划，TABLE函数部分，ROWS为空。
来单独检查一把：返回8168行，返回8000多行，足以导致走HASH JOIN了....而事实，我们至多返回200-300行：

所以每个步骤返回的行，是JOIN方式选择的重要因素，可以谷歌一把，TABLE函数返回8168就是个固定值，block_size=8K的时候就是这么大，可以说，这是ORACLE的一个限制。
只要你用了TABLE函数，就偏向于走HASH JOIN了

解决方式很多了，也就是要走NESTED LOOPS+index, 既然8168很大，那么我们就让优化器知道TABLE函数返回的行少点，才百行左右。
以下些都可以，当然也可以使用hint:use_nl等
CARDINALITY hint (9i+) undocumented;
OPT_ESTIMATE hint (10g+) undocumented;
DYNAMIC_SAMPLING hint (11.1.0.7+);
Extensible Optimiser (10g+).
因为SQL的SELECT部分只访问B，全部来自于TABLE函数，所以改写为子查询就可以了，使用子查询，自然distinct也就没有必要了，因为是semi join(半连接）。
最终改写使用cardinality hint让优化器知道B返回的行只有100行，你给我走NESTED LOOPS+INDEX，然后解决。
原来的sql：

修改后的sql：

效率提升了几十倍：

一个占72%的应用，我们提升几十倍后，那对系统性能明显是极好的。最终，在执行次数增加50%的情况下，w4sd08pa主机CPU使用率由原来的高峰期平均47%的使用率降低为23%。
这个问题能够解决有两个方面：
1、猜测并测试优化器的限制（table函数固定返回行8168)；2、实际返回的行200-300。两者缺一不可。如果实际返回的行就是几千上万，那么，单纯通过优化SQL，也是无法取得良好效果的。

楼主，图实在是太小了

大家嚎~ 吃完饭又回来了~我们继续。

刚才的set statistics_level直接写会输出结果，我们可以让他不输出结果：
1、sql内容放到文件中，前面加上set termout off （这样可以对输出结果不输出）
2、然后display_cursor文件中

用这种东西看执行计划，有时候很方便找出问题,否则我们自己得手动根据每个步骤对应的谓词，自己写SQL去计算真实返回的行，然后再来比较，用这个，ORACLE全帮我们干好了。

看懂执行计划执行顺序
一般怎么看执行计划呢？

COPY到UE里去。

用光标大法，找到入口，最先执行的，光标定位ID=0的，然后一直缩进向下，如果被挡住了，那么这部分就是入口了。
比如ID=10的继续索引，就被ID=11的挡住了，所以第10步就是入口。

找到入口后，反向光标来，利用平行级别的最上最先执行，最右最先执行原则，来看父操作与子操作的关系，移动光标即可。
比如这里的第13步，我只需要定位光标在PARTITION这个P前面，然后向上移动，立马就知道，它的驱动表是ID=5的VIEW，因为他们是对齐的。

然后看看之间的JOIN关系是不是有问题，返回的行估算等。
执行计划最右最上最先执行规则，有个例外，大家知道不？？就是通过以上规则，是不正确的。
（标量子查询）
SELECT a.employee_id,
a.department_id,
(SELECT COUNT(*) FROM emp_b b
WHERE a.department_id=b.department_id
) cnt
FROM emp_a a;
比如这个ID=2的在前面，但是它事实上是被ID=3的驱动的，也就是被emp_a驱动的，这违背了一般的执行计划顺序规则，平时注意点就行了，标量子查询谓词里会出现绑定变量，比如这里的：B1，因为每次带一个值去驱动子查询。