最近關於Oracle資料庫的一個問題和大家分享一下。

我公司在運營的空中充值業務系統，現在的業務量大概是每天3萬筆充值交易左右(和競爭對手不好比:()，在最近的這段時間的最佳化過程中，為了解決報表查詢緩慢的問題。我在主要的幾張表上加了索引，加了索引以後呢。報表速度的確快了很多，但是帶來的問題是交易速度緩慢了不少，每天業務高峰期老是出現充值擁堵的問題。而且這樣的時間持續了2周時間，把全公司的人都急懷了。
後來透過監控索引，回憶變更記錄，在測試環境上對比分析重於發現是這幾個索引的問題。把這幾個索引Drop了以後，問題就解決了。

在解決這個問題的過程中，用到了一個索引監控的方法和大家分析一下（也是從 《Oracle 9i 效能調整》這本書上學習過來的）。

1.以Owner使用者登入
對要監控的索引執行如下命令
alter index CHARGE_IDX1 monitoring usage;
alter index CHARGE_IDX2 monitoring usage;
alter index CHARGE_IDX3 monitoring usage;

2.查詢 select * from v$object_usage t where t.monitoring='YES'
INDEX_NAME TABLE_NAME MONITORING USED START_MONITORING END_MONITORING
----------------- ----------- ---------- ---- ------------------- -------------------
CHARGE_IDX1 TCHARGE YES NO 11/27/2007 15:41:28
CHARGE_IDX2 TCHARGE YES NO 11/27/2007 15:41:29
CHARGE_IDX3 TCHARGE YES NO 11/27/2007 15:41:29

可以看到 CHARGE_IDX1，CHARGE_IDX2，CHARGE_IDX3 已經在開始監控的了。

3.過一段時間（比如一天），再去看select * from v$object_usage t where t.monitoring='YES'，如果索引使用的話USED就為YES了
INDEX_NAME TABLE_NAME MONITORING USED START_MONITORING END_MONITORING
----------------- ----------- ---------- ---- ------------------- -------------------
CHARGE_IDX1 TCHARGE YES YES 11/27/2007 15:41:28
CHARGE_IDX2 TCHARGE YES NO 11/27/2007 15:41:29
CHARGE_IDX3 TCHARGE YES NO 11/27/2007 15:41:29

對USED為NO的索引根據情況可以根據需求進行刪除（drop）

4. 完畢後記得關閉索引監控
alter index CHARGE_IDX1 nomonitoring usage;
alter index CHARGE_IDX2 nomonitoring usage;
alter index CHARGE_IDX3 nomonitoring usage;

此外在解決這個問題的另一個感受就是加索引一定要小心。當初為了解決Full Table Scan的查詢，簡單的在資料表上加了索引，殊不知加了索引對日常業務的影響有那麼大（原來1秒4筆的，變成了3秒/筆）。看來只要Full Table Scan不在業務高峰期問題也是可以接受的（在晚上查詢慢一點有何妨？）。如果要解決報表查詢的問題，應該透過資料複製、資料轉移、建立點陣圖索引等方法解決，簡單的增加索引不是解決問題的方法。

[@more@]