DB2 開發與管理過程中，許多「約定俗成」的做法實則源於舊版本限制或誤解，可能導致效能瓶頸、維護困擾甚至資料風險。本文針對六大高頻誤區進行深度糾偏，提供基於現代 DB2 (v10.5+) 架構的最佳實踐指引。
錯誤觀點：物理模型必須 1:1 對應邏輯模型，任何偏離都是設計缺陷。
事實真相：物理設計為效能優化服務，適度反正規化、分區、叢集、物化視圖、摘要表等物理結構調整，往往無對應邏輯實體。
最佳實踐：邏輯模型保持純淨業務語義；物理模型引入分區鍵、冗余欄位、索引組織表、MQT (Materialized Query Table) 等優化結構，兩層透過 View/Stored Procedure 隔離。
錯誤觀點：BP0 是系統預設，將所有表空間關聯 BP0，DB2 會智慧管理。
事實真相：BP0 僅適用於極小記憶體環境 (如 < 40MB)、無專職 DBA、不考慮效能的場景。系統目錄 (SYSCATSPACE) 必須在 BP0，但用戶資料嚴禁放入 BP0。
最佳實踐：建立專用緩衝池：
•BP_4K_OLTP(4K 頁面，隨機存取核心表)
•BP_16K_DSS(16K 頁面，大表掃描、數倉)
•BP_32K_LOB(32K 頁面，LOB/XML 大物件)
依存取模式映射表空間至對應緩衝池，監控命中率目標 > 95%。
錯誤觀點：排序、哈希連接、物化視圖等操作使用 DSNDB07，全為循序 I/O。
事實真相：DSNDB07 含高達 45% 隨機 I/O (典型 3-10%)，源於工作檔頁面的隨機存取模式。
最佳實踐：
• 將 DSNDB07 容器置於高效能儲存層 (SSD/NVMe)
• 調大SORTHEAP、SHEAPTHRES_SHR減少溢寫磁碟
• 監控MON_GET_TABLESPACE中 DSNDB07 的隨機/循序讀寫比
錯誤觀點：變長欄位放最後可避免行遷移、提高更新效能。
事實真相：唯有「高頻更新、非壓縮表」才受益於列末尾放置。唯讀/低更新表、壓縮表 (行固定長度)、含 DEFAULT 值的欄位，放置位置影響極小。盲目置末反而可能破壞索引前綴相關性。
最佳實踐：
• 依存取頻率、關聯性排序欄位：主鍵、高選擇性索引欄位、常用 WHERE/JOIN 欄位前置
• VARCHAR 欄位若常用於查詢條件，前置優於置末
• 啟用COMPRESS YES後，行格式固定，位置無關緊要
錯誤觀點：依業務流程順序撰寫 SQL/程式碼，如「先查客戶、再查訂單、再查明細」。
事實真相：邏輯流程不考慮存取路徑成本。OLTP 交易中，最優路徑往往是「由高選擇性條件驅動、利用索引直接定位、避免巢狀迴圈掃描」。
最佳實踐：
• SQL 撰寫以資料流最小化為目標：早期過濾、下推謂詞、利用索引覆蓋
• 使用WITH(CTE) 邏輯分層，實際執行計劃由優化器重寫
• 關鍵交易 SQL 必經EXPLAIN驗證存取計劃
錯誤觀點：SQL 只負責 CRUD，複雜計算、流程控制放應用層 (Java/C#/Python)。
事實真相：SQL 是集合運算語言，擅長批次集合處理。將邏輯下推至資料庫層，可避免網路往返、資料傳輸、應用層迴圈。最大誤區是將 SQL 當「I/O 處理器」而非「集合處理器」。
最佳實踐：
• 複雜聚合、多表關聯、窗口函數、遞歸查詢 (CTE)、樞紐/反樞紐、JSON/XML 處理 → 全在 SQL 完成
• 應用層專注：業務編排、外部 API 呼叫、安全驗證、序列化、異常處理
• 使用預存程序/編譯單元封裝複雜 SQL 邏輯，提供介面給應用層
| 領域 | 反模式 | 最佳實踐 |
|---|---|---|
| 建模 | 邏輯=物理 1:1 | 分層建模：邏輯純淨、物理優化、視圖隔離 |
| 記憶體 | 全丟 BP0 | 多緩衝池策略：依頁面大小、存取模式分離 |
| 臨時空間 | 忽視 DSNDB07 | SSD 承載、調大排序堆、監控隨機 I/O 佔比 |
| 表設計 | VARCHAR 強制置末 | 依存取模式排序：高選擇性、高頻查詢欄位前置 |
| SQL 撰寫 | 遵循業務流程順序 | 目標導向：最小化掃描行數、最大化索引利用 |
| 邏輯分層 | 應用層處理集合運算 | SQL 下推：集合運算留資料庫、應用層做編排 |
DB2 擁有業界最強大的優化器、最豐富的 SQL 功能集 (OLAP、XML、JSON、時序、空間、圖)。深度掌握 SQL 能力、信任優化器、善用物理設計工具，是從「能用」邁向「高效、穩定、可擴展」的關鍵。建議團隊建立 SQL 開發規範文檔、關鍵 SQL 審核機制、效能基準測試基線，讓最佳實踐沉澱為組織資產。
