今晚（当然还差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的执行计划，因为显示的缘故做了一定的裁剪。
©著作权归作者所有：来自51CTO博客作者Larry.Yue的原创作品，如需转载，请注明出处，否则将追究法律责任
ORACLE数据库PARTITIONORACLE足迹
共同学习，写下你的评论
评论加载中...
作者其他优质文章
