Oracle 建立索引的五大限制條件與效能平衡實務

索引能加速查詢，但每次 DML 都需同步維護所有索引，索引過多反拖垮寫入效能。本文歸納五大「不宜建立索引」場景、多表 JOIN 索引設計、更新與查詢平衡點判斷，助您制定精準索引策略。

五大不宜/謹慎建立索引場景

1. 小資料量表（< 100 列）
   如參數表、部門表、帳號表。全表掃描成本極低，索引維護成本反而較高。直接全表掃描即可。
2. 大表但極少查詢
   如中繼資料表 AD_Table、稽核日誌表。僅建立表層級索引（PK/UK），不建立欄位級次要索引。
3. NULL 值欄位視業務頻率決定
   例：id_card_no 常用 WHERE id_card_no IS NULL 查詢未建檔員工 → 建 Bitmap 索引（支援 NULL）。
   若查詢頻率低 → 不建索引。
4. 高頻更新欄位
   如 last_login_time、account_balance。每次更新皆觸發索引維護，評估「查詢加速收益」是否大於「寫入延遲成本」。
5. 重複度極高且非查詢條件
   如 status='ACTIVE' 佔 99%，查詢通常針對 'INACTIVE'。此欄位建索引效果差，改用 CASE WHEN 函數索引或部分索引（12c+）。

多表 JOIN 索引設計原則

• 連接鍵（FK/PK）必須建立索引，否則大表 JOIN 會退化為 Hash Join + Full Scan。
• 外鍵欄位若無索引，DML 父表時需全表掃描子表檢查 RI，嚴重阻塞。
• 複合索引順序：(join_col, filter_col) 讓單一索引同時服務 JOIN 與 WHERE 過濾。

更新速度 vs 查詢速度：尋找平衡點

實務檢核清單

• [ ] 表列數 < 100 → 不建次要索引。
• [ ] 表從未出現在慢 SQL TOP 10 → 檢視是否可刪除索引。
• [ ] 索引欄位出現在 WHERE/JOIN/ORDER BY 中？否則候選刪除。
• [ ] 高頻 DML 表的索引數量 ≤ 5（含 PK）。
• [ ] 定期執行 DBMS_STATS.GATHER_TABLE_STATS 並檢視 USER_INDEXES.LAST_ANALYZED。

索引設計是「減法藝術」：從業務查詢模式反推必要索引，刪除其餘。定期審視 V$OBJECT_USAGE（監控索引使用情況），勇於刪除長期未用索引，才能維持系統長期健康。