今晚（当然还差14分钟就到明天了），对一张有19956517条记录的表进行特定SQL的优化操作。问题很快解决，原本需要56秒到1分半左右得到结果集的SQL，现在小于0.3秒。其实问题很简单，分裂（SPLIT）PARTITION后，没有及时更新本地索引！【如果有兴趣可以看看我写的有关分区SPLIT的博文】 该表有一个MESSAGE_ID作为主键，还有一个terminal_id字段的本地索引。 完成后，突然想看看COUNT全表数据性能如何。几经周折无大的提高。 后来想使用HINT得到突破，但是却有些另外的发现。 SQL> SELECT /*+ index (XXX_LOG INX__LOG_001)*/count(TERMINAL_ID) FROM XXX_LOG ;Execution Plan----------------------------------------------------------Plan hash value: 1657932776---------------------------------------------------------------| Id | Operation | Name | Rows | Bytes ---------------------------------------------------------------| 0 | SELECT STATEMENT | | 1 | 13 | 1 | SORT AGGREGATE | | 1 | 13 | 2 | PX COORDINATOR | | | | 3 | PX SEND QC (RANDOM) | :TQ10000 | 1 | 13 | 4 | SORT AGGREGATE | | 1 | 13 | 5 | PX BLOCK ITERATOR | | 19M| 236M| 6 | TABLE ACCESS FULL| XXXX_LOG | 19M| 236M---------------------------------------------------------------但是发现执行计划并没有使用本地索引，而是继续全表扫描！难道ORACLE的OPTIMIZER坚持自己的意见？！ 接下来换用HINT提示使用主键：SQL> SELECT /*+ index (XXX_LOG SYS_C0021352)*/ count(MESSAGE_ID) FROM XXX_LOG;Execution Plan----------------------------------------------------------Plan hash value: 3940329838-------------------------------------------------------------------------| Id | Operation | Name | Rows | Cost (%CPU)| Time |-------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 1 | 96181 (1)| 00:19:15 || 1 | SORT AGGREGATE | | 1 | | || 2 | INDEX FULL SCAN| SYS_C0021352 | 19M| 96181 (1)| 00:19:15 |------------------------------------------------------------------------- 发现计划正常使用了HINT提示的主键(SYS_C0021352)。 结论：看来ORACLE的优化器不接受HINT使用本地索引的指示！ -:)--- 环境： ORACLE版本：10.2.0.1 OS ：HP-UX B.11.23 U ia64 显示的表名等信息因为涉及保密原因，做了一定的屏蔽。 SQL的执行计划，因为显示的缘故做了一定的裁剪。
本文转自Be the miracle!博客51CTO博客，原文链接http://blog.51cto.com/miracle/52664如需转载请自行联系原作者
Larry.Yue
