DB2領域流傳著大量「經驗之談」，實則為歷史版本殘留、特定場景泛化、邏輯設計與物理實現混淆產生的認知陷阱。本文系統梳理二十大核心誤區，提供誤區描述 → 實際真相 → 根因解析 → 正確實踐的四層辨析框架。
| # | 誤區描述 | 實際真相 | 核心根因 | 正確實踐 |
|---|---|---|---|---|
| 1 | 邏輯設計應完全映射物理設計 | 物理設計為性能須偏離邏輯模型 (非規範化、分區、冗余列、MQT) | 混淆「業務建模」與「存儲優化」兩個設計層面 | 邏輯模型規範化，物理模型性能化，雙層映射文檔化 |
| 2 | 所有對象放入BP0讓DB2自管 | BP0僅放系統目錄；用戶數據必須按訪問模式分離到專用BP | 早期內存受限時代的妥協方案，現代服務器內存充裕 | 建立BP_4K_RANDOM、BP_8K_SEQ、BP_16K_DW、BP_32K_LOB等專用池 |
| 3 | DSNDB07(工作文件) 100%順序訪問 | 隨機訪問佔3%-45%(典型10%)，源於排序溢出、哈希連接、物化視圖 | 忽略複雜查詢中的中間結果集物理化特性 | 工作文件表空間配大頁(16K/32K)、多容器條帶、專用緩衝池 |
| 4 | VARCHAR列應總放行末 | 僅「高頻讀、極少更新」表適用；頻繁更新表放行末導致行遷移、性能災難 | 未區分「讀多寫少」與「讀寫均衡/寫多」負載特徵 | 讀多寫少→行末；其它→固定長或行首；壓縮表更不適用 |
| 5 | 程式應按邏輯流程編碼 | SQL是集合操作語言，邏輯流程(過程化)與優化器思維(聲明式)根本衝突 | 將過程化思維強加於聲明式語言 | SQL編碼思維：描述「要什麼」而非「怎麼取」；利用CTE分解複雜邏輯 |
| 6 | 大多數業務邏輯不在SQL中處理 | SQL/Turing完備，窗口函數、遞歸CTE、MATCH_RECOGNIZE可處理極複雜邏輯 | 將SQL降級為「I/O接口」，忽視其「集合處理器」本質 | 業務邏輯下推至SQL層(存儲過程/視圖/CTE)，應用層專注流程編排 |
| 7 | 代碼與引用表應配合RI(Referential Integrity)使用 | RI用於真實父子關係強制完整性，非編輯驗證捷徑；編輯驗證屬應用層 | 將「業務規則驗證」錯置於「數據完整性約束」 | RI僅用於核心主外鍵；編輯驗證用CHECK約束/觸發器/應用層 |
| 8 | 表至多1-2個索引 | 索引數量由查詢負載決定，OLTP表10-20索引常見，DW表更多 | 早期存儲昂貴/維護開銷大時代的經驗固化 | 基於負載分析建立索引，定期清理LASTUSED為舊的索引 |
| 9 | 非分區索引(NPI)不應用於大表 | NPI對跨分區查詢、全表掃描替代、XML索引、空間索引至關重要 | 過度關注「分區剪枝」忽視「全局導航」需求 | 大表必建關鍵NPI(如時間戳、租戶ID)，配合分區索引雙重覆蓋 |
| 10 | 大表必須分區 | 現代硬件/優化器下，60億行+單表無分區仍可高性能；分區增加維護複雜度 | 「大表=性能差」的歷史創傷後應激 | 分區決策基於：維護窗口、數據生命週期、查詢剪枝收益、而非單純行數 |
| 11 | DB2默認值即最佳值 | 默認值隨版本變化、針對「平均負載」優化，生產環境必須按負載調優 | 將「開箱即用」誤讀為「生產就緒」 | 關鍵參數(LOCKLIST, SORTHEAP, PCKCACHESZ, DFT_DEGREE等)必須基準測試調優 |
| 12 | WHERE子句禁用否定謂詞 (NOT/!=/<>) | 僅「單一否定謂詞導致全表掃描」時有害；複合謂詞中否定常被優化器高效處理 | 未理解優化器謂詞推導與索引掃描範圍確定機制 | 否定謂詞正常使用；關鍵路徑通過EXPLAIN驗證訪問路徑 |
| 13 | EXPLAIN輸出足以判斷計劃優劣 | EXPLAIN缺失：查詢塊執行順序、一/二階段謂詞、塊執行耗時、實際行數vs估算行數 | 將「計劃結構」等同於「執行性能」 | 必須結合db2exfmt、MON_GET_PKG_CACHE_STMT、實際執行統計綜合判斷 |
| 14 | EDM池不宜過大以免分頁 | EDM池通過擴展存儲分頁提升性能；過小導致結構重建、編目鎖爭用 | 混淆「虛擬內存分頁」與「磁盤I/O分頁」 | EDM池配大不配小；監控EDM_POOL_HIT_RATIO > 95% |
| 15 | Extent(區)大小不影響其他 | Extent影響預取、條帶、容器管理、重分佈並行度；SAN/ESS緩存只部分掩蓋 | 忽視存儲軟體層面的Extent語義(分配單位、並行單位) | Extent Size按訪問模式設置：順序大(32-64)、隨機小(2-4) |
| 16 | 關係劃分(水平/垂直)在DB2中不適用 | MQT、分區表、MDC、範圍分區、表空間隔離均是關係劃分的現代實現 | 將「傳統手工劃分」等同於「關係劃分理論」 | 大規模採用MQT預聚合、分區表生命週期、MDC多維聚類 |
| 17 | 所有包綁定到兩個計劃(批處理/在線) | 包/計劃機制已演進：包版本控制、動態SQL、集合隔離、綁定選項精細化 | 早期靜態SQL時代的簡化管理模式 | 按應用模塊/業務域/隔離級別組織包集合，利用PKLIST精細控制 |
| 18 | 未提交讀(UR)是壞東西 | UR是高性能利器：報表/查詢/只讀服務大幅降低鎖爭用；需業務容忍髒讀 | 將「一致性風險」絕對化，忽視「性能收益/業務容忍度」權衡 | 只讀報表/歷史查詢/數據導出強制WITH UR；核心交易嚴禁 |
| 19 | 無超時/死鎖即無鎖問題 | 鎖等待時間(而非死鎖計數)才是性能殺手；統計AVG_LOCK_WAIT_TIME而非DEADLOCK_COUNT | 關注「災難性結果」忽視「慢性損耗」 | 監控鎖等待時間分佈、熱點對象、持有者SQL；目標P99_LOCK_WAIT < 100ms |
| 20 | ESA壓縮總是好的 | 壓縮增加CPU、影響更新性能、可能導致行遷移；須按表/分區評估收益比 | 將「空間節省」絕對化，忽視「CPU/更新/讀放大」代價 | 決策矩陣：只讀/歷史/大行→壓縮；高頻更新/小行/關鍵路徑→不壓縮 |
這二十大誤區涵蓋了物理設計、內存管理、存儲佈局、索引策略、分區哲學、優化器認知、鎖機制、壓縮經濟學八大核心領域。打破這些認知鎖鏈，建立「分層解耦、負載導向、版本感知、實證驗證」的現代DB2性能工程思維，是DBA從「經驗主義者」進階為「性能架構師」的必經之路。
