性能調優不僅是參數調整，更是打破固有認知偏見的過程。本文梳理 20 個高頻誤區，對比「流傳認知」與「實戰真相」，幫助 DBA 建立科學調優思維。
| # | 流傳認知（誤區） | 實戰真相 |
|---|---|---|
| 1 | 邏輯設計應完全映射物理設計 | 為性能可適度反範式化、分區、冗余列、物化視圖，物理設計不受邏輯約束 |
| 2 | 所有對象放入 BP0 讓 DB2 自管 | 僅極小內存（<10k 頁）且無調優資源時才這樣做。生產環境應按表空間/對象類型劃分多緩衝池，BP0 僅留目錄表 |
| 3 | DSNDB07 (工作文件) 100% 順序訪問 | 實際 3%-45% 隨機讀寫（排序溢寫、雜湊連接溢寫），需獨立緩衝池與高速磁盤 |
| 4 | VARCHAR 應放行末 | 唯有「高頻更新、低讀取」表才放行末；多讀少寫表放行首減少 CPU 開銷，壓縮表更不適用 |
| 5 | 代碼應遵循邏輯流程編寫 | OLTP 核心路徑需按「最小掃描、最早過濾、索引覆蓋」重寫，偽代碼邏輯常導致全表掃描 |
| 6 | 大多數業務邏輯不在 SQL 中處理 | SQL 是集合處理器，擅長聚合/連接/窗口函數，將邏輯下推到引擎層通常比應用層快數量級 |
| 7 | 代碼檢查應用 RI (Referential Integrity) | RI 僅用於真實父子關係強制完整性，不用作應用層輸入驗證的捷徑（觸發器/應用驗證更靈活） |
| 8 | 表至多 1-2 個索引 | 索引數量由查詢模式決定，OLTP 表 5-10 個索引常見，關鍵是監控 INDEXUSED 清理無效索引 |
| 9 | 非分區索引 (NPI) 不可用，尤其大表 | NPI 對跨分區查詢、全局唯一性約束不可或缺，現代版本已優化 NPI 維護開銷 |
| 10 | 大表必須分區 | 分區主要為管理便利（滾入/滾出、備份粒度），純性能視角 60 億行單分區表同樣可高效運行 |
| 11 | DB2 默認參數即最佳 | 默認值隨版本變化，關鍵參數（如 CURRENTDATA、LOCKSIZE、OPTIMIZATION LEVEL）必須按負載調優 |
| 12 | WHERE 子句禁用否定謂詞 (NOT, !=, <>) | 僅當否定謂詞導致全表掃描時才需改寫；多數情況下引擎內部過濾效率更高 |
| 13 | 只靠 EXPLAIN 判斷訪問路徑優劣 | EXPLAIN 缺失：塊執行順序、一/二階段謂詞、實際耗時。需結合 Visual Explain、db2batch、監控指標綜合判斷 |
| 14 | EDM 池不宜過大防分頁 | EDM 池適度分頁（擴展存儲）反而優於頻繁重建內部結構，建議配置略大於工作集 |
| 15 | 擴展 (Extent) 不影響性能 | SAN/ESS 緩存掩蓋了部分影響，但擴展分配/回收仍有元數據鎖開銷，大表預分配大擴展可減少爭用 |
| 16 | 關係劃分 (Horizontal/Vertical Partitioning) 不用 | BI/市場分析系統大量使用分區表、物化視圖、列存表實現分區裁剪與列裁剪 |
| 17 | 所有包綁定到兩個計劃 (批處理/在線) | 包粒度綁定支援版本隔離、權限分離、編譯選項差異化，過度合併反而增加綁定衝突 |
| 18 | 未提交讀 (UR) 是壞事 | UR 是高併發唯讀查詢的利器（報表、ETL 掃描），無鎖開銷，只要業務可容忍臟讀即可大膽使用 |
| 19 | 無超時/死鎖即無鎖問題 | 鎖等待時間才是核心指標。大量短等待雖不死鎖，但嚴重拖慢響應。需監控 LOCK WAIT TIME 而非僅計數 |
| 20 | ESA 壓縮總是好 | 壓縮換 CPU 換 I/O，CPU 瓶頸時反而降性能。每張表需壓測決定，不可全局開關 |
