很多朋友都问过我优化SQL的事情。我觉得在我不断地鼓励下，很多朋友现在都知道优化SQL之前要先看看执行计划，也在优化中获得了很多快乐。但是今天有人问我执行计划应该怎么看。我觉得这是个值得写一写的东西。
先告诉大家一个原则，看执行计划的时候，从第一行开始向右下看，一直到最右边。如果有并列的，那么先上再下。如果没并列，右边的先执行。
闲话少说，先上图吧：
这是一个简单的SQL的执行计划，这个执行计划告诉我们，id=2的最先执行，然后是id=3的，然后执行id=1的。
首先对test进行一次全表扫描，这一步返回rows=2，CPU的消耗为2。接下来对test1进行一次全表扫描，这一次返回的rows为2，CPU的消耗为3。接下来对这两个结果进行一次哈希连接（hash join），返回rows=1，这里的CPU消耗为6，但是需要注意，这次是我的语句赶寸了，6=2X3，但是哈希连接需要的CPU COST绝对不会恰恰是之前执行的操作的CPU COST之积，特别说明一下。至此，我们的oracle对这个语句的执行计划结束。
这个执行计划是怎么得到的？既然是计划，那么绝对不是把这个语句先执行一遍，然后把这个计算出来，那样的话这个执行计划就成了事后诸葛亮了。这个执行计划是oracle根据统计信息得到的。那么这个执行计划就有可能不准，请大家看看我的语句以及执行出来的结果：
SELECT A.SER_ID, B.OWNER FROM TEST A, TEST1 B WHERE A.AREA_ID = B.OWNER;
结果如图：
怎么样？绝对不是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。
现在可以总结一下了：执行计划的准确性（主要指数据返回，数据量大小）由统计信息的准确性决定。
©著作权归作者所有：来自51CTO博客作者wingsless的原创作品，如需转载，请注明出处，否则将追究法律责任
Oracle休闲 优化oracle管理
1