DB2 SQL 編碼優化基礎：從優化器原理到三大黃金法則

前言

構建基於 IBM DB2 UDB 與 Borland 工具（Delphi、C++Builder、Kylix）的企業應用，程序員可借助 DB2 優化器處理複雜 SQL 並給出有效存取路徑。但拙劣編碼的 SQL 仍會拖垮性能。本文揭示優化器工作原理，給出編寫高效 SQL 的三大核心准則，並針對 Delphi 等工具提供進階技巧。

SQL 基礎回顧

• 聲明式非過程化：只關注「要什麼數據」，不關心「怎麼取」。DB2 負責生成存取路徑（Access Path）。
• 集合級處理：單條語句作用於多行，非逐行導航。
• 靈活性與性能陷阱：功能等價的 SQL（如 BETWEEN vs <=/>=、IN vs OR、連接 vs 子查詢）性能可能天差地別。
• 物理數據獨立性：優化器屏蔽物理存儲細節，索引增刪無需改應用代碼。

優化器：DB2 的心臟與大腦

優化器是基於成本的專家系統：解析 SQL → 查詢系統目錄統計信息 → 應用查詢成本公式（CPU、I/O、統計信息、SQL 文本） → 選擇總成本最低的存取路徑。四步驟：語法驗證、環境分析優化、生成機器指令、執行/存儲。

性能調優三大前提

1. 統計信息必須最新： RUNSTATS 定期收集表/列/索引/表空間統計，無統計信息優化器「盲人騎瞎馬」。
2. 構建適當索引： 最重要單一動作。以 WHERE EMPNO='000010' AND DEPTNO='D01' 為例，(EMPNO, DEPTNO) 復合索引通常最優。權衡因素：修改開銷、現有索引覆蓋、查詢業務重要性、是否實現「僅索引訪問」（含覆蓋列）。
3. 理解優化器成本模型： 非黑盒，可通過 EXPLAIN、Visual Explain 觀察計劃。

SQL 編碼三大黃金法則

法則一：SELECT 列表只寫真正需要的列 —— 拒絕 SELECT *

害處： 表結構變更導致程序崩潰；傳輸無用列消耗網絡/CPU/內存；可讀性差、易引入隱性 Bug。正例： SELECT LASTNAME, SALARY FROM EMP WHERE EMPNO='000010';

法則二：不要檢索已知的值

反例： SELECT EMPNO, LASTNAME, SALARY FROM EMP WHERE EMPNO='000010'; — EMPNO 已在 WHERE 給出，重複檢索純屬浪費。

法則三：在 SQL WHERE 子句中過濾，而非應用層過濾

反例： 全表讀回應用層再判 SALARY > 50000。正例： SELECT EMPNO, LASTNAME, SALARY FROM EMP WHERE SALARY > 50000; — DB2 過濾後傳輸少量行，I/O/CPU 雙贏。

進階技巧：參數化查詢與工具專屬優化

參數化查詢

用參數標記（?）替代字面值，優化器可重用存取路徑，避免重複優化開銷。應用設計為用戶運行時提供參數值。

Delphi / C++Builder / Kylix 專屬優化

• 優先 dbExpress： 跨平台動態 SQL 接口，性能優於 ODBC/JDBC/ADO。
• 頻繁 COMMIT： 釋放鎖，避免長事務阻塞並發。修改數據後及時 COMMIT，異常時 ROLLBACK。
• 限制返回行數： FETCH FIRST n ROWS ONLY 截斷結果集（超過報 SQLCODE +100），適配分頁顯示。
• 優化器提示： OPTIMIZE FOR n ROWS 告訴優化器優先快速返回前 n 行（不截斷），適配分批獲取場景。
• 只讀游標標記： FOR READ ONLY 消除歧義，DB2 可應用更激進優化（Delphi 不支持位置更新）。

結語

掌握優化器原理與三大法則，性能即刻提升。但這只是冰山一角：連接、子查詢、集合運算、存取路徑分析……精通之路漫長。享受探索樂趣，構建極速應用！