Oracle SQL 共享池匹配機制詳解：Hash 值、語義一致性與執行環境敏感度

為什麼要避免硬解析？

硬解析耗費大量 CPU 與閂資源。若共享池有現成副本，可軟解析直接重用執行計畫與優化決策，極大降低開銷。匹配過程分兩階段：

階段一：文字與 Hash 值完全一致

1. 計算提交 SQL 的 Hash 值，與共享池現有 V$SQL.HASH_VALUE、V$SQLAREA.HASH_VALUE 比對。
2. Hash 碰撞極罕見，但 Hash 相同不保證可共用，必須進入語義再驗證。

經典反例：同文字、不同物件

• 用戶 A：自有表 EMP，執行 SELECT * FROM emp。
• 用戶 B：自有表 EMP，執行相同文字。
• 用戶 C：查詢公用同義詞 EMP 指向 SCOTT.EMP。
• 用戶 SCOTT：查詢自有 EMP。

四者 SQL 文字與 Hash 全同，但僅 C 與 SCOTT 可共用（指向同一物件）。A、B 各自硬解析。

階段二：執行環境完全一致

即使物件相同，環境差異也會導致不同執行計畫，故不可共用：

• HINT 差異：/*+ FIRST_ROWS */ vs /*+ ALL_ROWS */。
• Session 參數：WORK_AREA_SIZE_POLICY、OPTIMIZER_MODE、NLS_SORT、CURSOR_SHARING 等。

實驗：同一 SQL，改變 WORK_AREA_SIZE_POLICY 導致不同計畫，驗證環境敏感度。

優化器介入（硬解析核心）

• 有統計資訊 → CBO 列舉所有可行計畫，計算 Cost，選最低。
• 無統計資訊 → RBO 依固定規則選擇。

此步驟最耗資源，強化「避免硬解析」的必要性。

最佳實踐：提升軟解析率

1. 使用綁定變數：SELECT * FROM emp WHERE empno = :b1，而非字串拼接。
2. 統一編碼風格：大小寫、縮排、換行標準化（可用格式化工具）。
3. 固定 Session 環境：應用連線池初始化時設定統一參數。
4. 收集穩定統計資訊：讓 CBO 決策一致，減少計畫翻盤。

結語

共享池匹配是「文字 Hash → 語義物件 → 環境參數」三重過濾。唯有三者皆同，才能軟解析。從開發端落實綁定變數與編碼規範，是提升軟解析率、降低硬解析風暴最具槓桿效應的手段。