今晚（當然還差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的執行計劃，因為顯示的緣故做了一定的裁剪。