DB2 V9.7 語句集中器：消除動態 SQL 編譯開銷的關鍵技術

前言：OLTP 環境下的效能挑戰

在線交易處理（OLTP）環境中，每秒可能執行成千上萬條 SQL 語句。在 DB2 V9.7 之前，每條動態 SQL 執行都需要經過完整的編譯過程——解析、語義檢查、優化、生成存取路徑。編譯極度消耗 CPU 資源，若大量相似但文本不同的 SQL（僅字面值不同）重複編譯，系統吞吐量將嚴重受限。

動態 SQL 與靜態 SQL 的本質差異

DB2 區分兩類 SQL：

• 靜態 SQL：在 BIND 階段即確定執行計劃，運行時直接從包緩存調用，零編譯開銷。
• 動態 SQL：每次執行皆需即時編譯。若計劃未在包緩存命中，則觸發完整編譯流程。

DB2 以 SQL 文本為鍵值進行哈希匹配。哪怕只有一個字母大小寫差異，哈希值便不同，導致被視為不同語句，無法共享計劃。例如：

select firstnme, lastname from employee where empno='000020'
select firstnme, lastname from employee where empno='000070'

雖然兩者邏輯相同、執行計劃一致（皆走索引 PK_EMPLOYEE），DB2 仍會各自編譯一次，白白浪費 CPU 週期。

語句集中器：核心機制與啟用方式

DB2 V9.7 引入 Statement Concentrator（語句集中器），在伺服器端將動態 SQL 中的字面值替換為參數標記（如 :L0），使「結構相同、字面值不同」的語句映射為同一內部表示，從而共用單一編譯計劃。

兩種啟用層級

最佳實踐：優先採用連接級啟用，因其控制力最精細，且為全產品線通用標準。

實戰驗證：編譯次數從 N 降為 1

啟用後重新執行上述兩條 SQL，再用 db2 get snapshot for dynamic sql on sample 觀察：

• 原始兩條 SQL 的「編譯數」與「執行數」均歸零；
• 新增一條參數化語句 select firstnme, lastname from employee where empno=:L0，編譯數 = 1，執行數 = 2，編譯耗時 218 ms。

顯而易見，兩次邏輯查詢僅編譯一次，CPU 開銷大幅降低。

監控與可見性說明

• 事件監視器、MON_GET_ACTIVITY_DETAILS 等介面會同時顯示「原始語句」與「修改後語句」。
• 其他監控介面僅顯示參數化後的語句文本。

預設僅替換前 100,000 個字面值，餘下保持原樣，實務上足以覆蓋絕大多數 OLTP 工作負載。

結語

語句集中器是 DB2 V9.7 為高併發 OLTP 量身打造的「編譯去重器」。正確啟用它，能以極低成本換取顯著的 CPU 節省與吞吐提升，是 DBA 與開發人員必須掌握的效能優化利器。