問題背景
在 Oracle 資料庫開發中，PL/SQL 觸發器是實現業務邏輯自動化的關鍵手段。許多初學者疑惑：當執行 DML（INSERT/UPDATE/DELETE）語句時，資料庫是如何檢測並決定是否觸發對應觸發器的？這個檢查機制是全域性的，還是針對特定表優化的？會不會影響效能？
核心機制：基於物件的事件驅動
Oracle 採用基於物件的事件驅動模型，而非全域掃描。具體運作流程如下：
- 觸發器註冊元資料：當你對表 `T` 建立 DML 觸發器時，Oracle 會在資料字典（`USER_TRIGGERS`、`USER_DEPENDENCIES`）中記錄該觸發器的元資料，並與表 `T` 建立依賴關係。
- DML 執行時的快速查找：當對表 `T` 發起 DML 操作時，執行引擎會直接查閱表 `T` 的相依元資料，判斷是否存在 `BEFORE/AFTER ROW/STATEMENT` 觸發器。此過程僅針對當前操作的表進行，不會掃描全資料庫的觸發器。
- 觸發條件評估：若存在觸發器，進一步評估 `WHEN` 條件子句（若有），條件滿足則觸發執行。
效能影響分析
結論：對效能影響極微，可忽略不計。
- 元資料快取：觸發器元資料位於 SGA 的 Library Cache 中，查找屬於記憶體操作，納秒級延遲。
- 無觸發器零開銷：若表無觸發器，依賴檢查極快，僅是一個標誌位判斷。
- 真正開銷在觸發器本體：效能瓶頸通常在觸發器內部的複雜 SQL、跨表操作或非必要的行級觸發器（建議改用陳述式觸發器或複合觸發器優化）。
最佳實踐建議
- 避免濫用行級觸發器：大批量資料操作時，行級觸發器會逐行觸發，開銷巨大；優先考慮陳述式觸發器或複合觸發器（Oracle 11g+）。
- 善用 `WHEN` 條件：在觸發器定義中加入 `WHEN (condition)` 子句，可在觸發器本體執行前過濾無關操作，減少上下文切換。
- 監控 `V$SESSION_WAIT`：若懷疑觸發器導致效能問題，可檢視 `latch: library cache` 或 `log file sync` 等等待事件。
總結
Oracle 觸發器檢測機制是針對目標表的元資料快速查找，非全域掃描。正確設計觸發器類型與條件，其效能開銷完全可控。初學者應專注於觸發器內部邏輯優化，而非擔心檢測機制本身。
