從 SELECT 語句看 Oracle 查詢處理全流程：解析、執行與提取原理

查詢處理四大階段總覽

一條看似簡單的 SELECT，在 Oracle 後台經歷客戶端發送 → 解析 → 執行 → 提取四大階段。理解此流程對 SQL 調優、故障排查、架構設計至關重要。

第一階段：客戶端 → 服務端進程

• 客戶端（如 SQL*Plus、JDBC）不處理任何邏輯，僅負責將 SQL 文本傳送至服務端。
• 服務端建立專用伺服器進程（或共用伺服器）對應每個客戶端連線，稱為「影子進程」。
• 所有解析、優化、執行、資料存取均在服務端進程完成。

第二階段：解析——最複雜的「小動作」

1. 庫快取檢查

檢查 Shared Pool 中是否存在相同 SQL 的執行計畫。命中則跳過後續解析步驟，直接執行（軟解析）。未命中則硬解析。

注意：資料庫端 Library Cache ≠ 應用端查詢快取。應用端快取可能導致髒讀，資料庫端保證一致性。

2. 語法檢查

驗證 SQL 是否符合語法規則。錯誤即回饋客戶端（ORA-009xx）。不檢查物件是否存在。

3. 語義檢查

驗證表名、欄位名、權限是否存在於資料字典。錯誤回饋（ORA-00904、ORA-00942）。順序固定：語法 → 語義 → 權限，調試時可利用此順序快速定位。

4. 物件解析鎖

在查詢物件上加共享鎖，防止 DDL 修改結構導致解析失效。

5. 權限檢查

驗證當前用戶是否具備 SELECT、EXECUTE 等權限。失敗回饋 ORA-01031。權限檢查在語法語義之後，故應用層常自行實作細粒度權限控制。

6. 優化器生成執行計畫

CBO 根據統計資訊、索引、約束、Hint 等生成最佳計畫，並將 SQL 文本 + 計畫 存入 Library Cache 供下次復用。

第三階段：執行

• 資料塊在緩衝區：直接從 Buffer Cache 讀取（邏輯讀），極快。
• 資料塊不在緩衝區：發起實體 I/O 從資料檔讀入 Buffer Cache（實體讀），再處理。
• 區分 SQL 快取與 資料快取，兩者機制、目的完全不同。

第四階段：提取

服務端進程將結果集透過網路協議（SQL*Net/Net8）傳回客戶端進程，完成一次查詢閉環。

實務啟示與最佳實踐

1. 善用繫結變數：提高軟解析率，減少硬解析 CPU 消耗。
2. WHERE 條件下推：盡早過濾資料，減少邏輯/實體讀。
3. 避免 SELECT *：只查必要欄位，減少網路傳輸、緩衝區壓力、排序成本。
4. 理解權限檢查順序：應用層權限控制可減輕資料庫負擔、提升彈性。
5. 監控等待事件：關注 latch: library cache、db file scattered read 等指標定位瓶頸。