Oracle SQL 解析深度解析：硬解析 vs 軟解析，官方文檔錯誤與 Tom Kyte 正名

兩類 SQL、兩種解析

• DDL：從不共用，每次皆硬解析。
• DML：視情況進行硬解析或軟解析。

官方文檔（8i OCP）舊版解析步驟（有誤）

1. 共享池搜尋現有副本
2. 語法驗證
3. 資料字典查找驗證表/欄定義
4. 取得物件分析鎖
5. 檢查用戶存取權限
6. 決定最佳執行計畫
7. 載入共享 SQL 區

舊認知：軟解析 = 步驟 1 找到副本後，只做步驟 5 權限檢查，省略 2-4、6-7。

Tom Kyte《Effective Oracle By Design》正名：真實解析流程

階段一：語法檢查

純文字層面檢查關鍵字拼寫、標點、子句順序。
例：SELET * FROM emp → ORA-00900 直接報錯，不進後續。

階段二：語義檢查

解析器查詢資料字典，驗證：

• 表/視圖/欄位是否存在？
• 用戶是否有權限存取？

例：SELECT * FROM emp 若當前用戶無 emp 物件且無同義詞 → ORA-00942。

階段三：共享池檢查（決定硬/軟解析）

語法、語義皆通過後，計算 SQL 文字的 Hash 值，於共享池尋找：

• 找到完全匹配（文字、語義、環境皆同）→ 軟解析，直接重用執行計畫。
• 未找到 → 硬解析，進入優化器產生執行計畫。

關鍵細節：什麼叫「完全匹配」？

1. 文字逐字相同：大小寫、空白、換行、註解皆須一致。
2. 語義相同：同樣文字指向不同物件（如不同 Schema 同名表）不共用。
3. 執行環境相同：OPTIMIZER_MODE、HINT、NLS 參數、WORK_AREA_SIZE_POLICY 等影響計畫的 session 參數須一致。

階段四：優化器產生執行計畫（硬解析核心開銷）

• 有統計資訊 → CBO 依成本評估數千萬候選計畫，選最低 Cost。
• 無統計資訊 → RBO 依規則選擇。

階段五：執行

依執行計畫存取資料，回傳結果。

結語

真實順序是：語法 → 語義 → 共享池匹配 →（硬解析：優化器）。軟解析非單純「省略前幾步」，而是前置檢查通過後發現可重用。理解此流程，方能從根源減少硬解析（綁定變數、統計資訊、參數一致性），提升系統吞吐。