在DB2資料庫管理的實務操作中，流傳著許多「經驗法則」與「不成文規定」。這些看似合理的建議，若未經驗證便盲目遵循，往往會成為效能瓶頸的隱形推手。本文整理了實務上最常見的20個DB2效能調校迷思，針對每一項給出事實釐清與專業建議，助您避開陷阱，精準優化資料庫效能。
迷思： 物理結構應完美映射邏輯模型。
事實： 物理設計需以邏輯結構為基礎，但為效能優化（如分區、索引、叢集）所做的物理調整，不受邏輯設計限制。靈活的物理設計是效能關鍵。
迷思： 簡化管理，僅使用預設BP0。
事實： 僅在記憶體極度受限（<10,000個4K頁）且無暇管理時才考慮。最佳實務：除系統目錄外，嚴禁將使用者物件放入BP0。應依存取模式建立專用緩衝池（BP16K, BP32K等）。
迷思： 暫存表空間純循序I/O，無需隨機I/O優化。
事實： 工作檔操作（排序、雜湊連接）產生大量隨機頁面存取，隨機I/O比例通常3%-10%，高峰可達45%。需配置足夠緩衝池與快速儲存裝置。
迷思： 避免更新時資料行位移，減少CPU。
事實： 唯有「高頻更新、低頻讀取」的表才適用。對於「高讀低寫」或壓縮表，置於末尾反而增加CPU開銷（需計算位移）。現代版本已優化VARCHAR處理，勿死守舊規則。
迷思： 程式結構對應業務流程即可。
事實： OLTP交易中，邏輯流程常導致「先查後更新」的長鎖定鏈。效能導向編碼應：縮短交易範圍、優先存取索引、避免游標循環，甚至需重構業務邏輯順序。
迷思： SQL僅作資料存取，商業邏輯放應用層。
事實： SQL具備豐富的集合運算能力（JOIN、窗格函數、CTE、MERGE）。將資料搬至應用層處理（Row-by-row）是效能大忌。能用單一SQL解決，絕不拆多條；善用「集合思維」替代「迭代思維」。
迷思： 用RI約束替代應用層驗證，省事又安全。
事實： RI應僅用於真實父子關係（如訂單-明細）。代碼表驗證宜用應用層快取或CHECK約束，避免RI鎖定競爭與級聯刪除風險。
迷思： 索引越多寫入越慢，控制數量。
事實： 索引數量應由查詢負載決定。OLAP系統常需十數索引支援多維分析。關鍵在於：定期監控索引使用率（`SYSCAT.INDEXES`），移除未用索引，而非設定人為上限。
迷思： NPI維護成本高，查詢易退化。
事實： NPI是跨分區唯一性約束、全域排序、未含分區鍵查詢的必要手段。配合`ALLOW REVERSE SCANS`、適當`PCTFREE`，NPI負擔可控。禁用NPI反而導致全表掃描。
迷思： 資料量大即需分區，否則效能差。
事實： 現代DB2（配合大頁面、記憶體壓縮、自適應壓縮）單分區表可支撐百億列級別。分區主要解決：資料生命週期管理（滾動刪除）、備份還原粒度、跨儲存層分級。純為效能而分區，往往得不償失。
迷思： IBM預設經過調校，開箱即用。
事實： 預設值面向「通用相容」，非「效能最優」。關鍵參數必須依負載調整：
- `LOCKLIST`/`MAXLOCKS`（鎖記憶體）
- `SORTHEAP`/`SHEAPTHRES_SHR`（排序堆疊）
- `STMM`（自動記憶體管理）啟用後仍需監控水位
- `CURRENTDATA`（游標穩定性）預設YES導致鎖升級，唯讀查詢建議NO
迷思： 否定謂詞導致全表掃描。
事實： 僅當否定謂詞為唯一存取路徑條件時才必然掃表。複合索引、範圍分區、MDC表均可高效支援否定查詢。關鍵在於：讓優化器有統計資訊、有合適索引，而非改寫業務邏輯。
迷思： 看EXPLAIN輸出（IXSCAN vs TBSCAN）定優劣。
事實： EXPLAIN不顯示：查詢塊執行順序、單/兩階段謂詞評估、實際執行時間、並行度、緩衝池命中率。需結合：
- `db2exfmt` 格式化報告
- `MON_GET_PKG_CACHE_STMT` 即時效能指標
- Visual Explain 圖形化分析
- 實際執行計畫（Section Actuals）
迷思： EDM Pool過大導致作業系統分頁，反降效能。
事實： EDM Pool儲存封裝快取、目錄快取、工作檔定義。**適度擴大EDM Pool（配合Large Page）可減少動態SQL編譯、目錄同步開銷**。分頁發生於實體記憶體不足，解法是加記憶體或啟用STMM，而非壓縮EDM Pool。
迷思： SAN/SSD下Extent大小無關緊要。
事實： 儲存控制器快取算法仍依Extent邊界預讀。過小Extent（<32頁）增加Metadata管理開銷；過大Extent造成空間浪費與平行I/O度不足。建議：OLTP 32-64頁，OLAP 128-256頁，並對齊RAID Stripe Size。
迷思： 分區表已取代手工分表。
事實： 在多租戶隔離、跨區域資料主權、極大表（>100億列）並行載入場景，手工分表（Union All View / MQT）仍具優勢：獨立統計資訊、獨立Reorg、獨立備份。DB2原生分區表（Range Partition）與應用層分表可共存互補。
迷思： 簡化計劃管理。
事實： 此為DB2早期版本（V2/V3）遺留惡習。現代版本：
- 套件獨立綁定、獨立版本控制
- 依應用模組劃分Collection
- 使用`BIND`選項`APREUSE`/`EXPLAIN`控制重編譯
單一巨大計劃導致：目錄鎖定競爭、套件失效連鎖、授權管理混亂。
迷思： 髒讀導致資料不一致，嚴禁使用。
事實： UR是唯讀報表、資料探勘、快照查詢的效能利器：
- 完全跳過列鎖/頁鎖
- 避免鎖升級與死鎖
- 吞吐量提升3-10倍
前提：業務可容忍「臨時不一致」，且無UPDATE/DELETE操作。
迷思： 只要不報SQL0911N/SQL0912N，鎖定就正常。
事實： **鎖等待時間**才是核心指標。大量短暫鎖等待（<1秒）雖不觸發逾時，但累積佔用CPU、增加交易回應時間。必須監控：
- `MON_GET_APPL_LOCKWAIT` 累積等待時間
- `LOCK_WAITS` / `LOCK_WAIT_TIME` 事件監控
- `LOCKLIST` 使用率水位
迷思： 壓縮省空間又省I/O，全開無害。
事實： 壓縮帶來CPU換I/O交換。以下場景慎用或禁用：
- 高頻更新的OLTP熱點表（壓縮/解壓CPU成本 > I/O節省）
- 已高度壓縮的二進位資料（BLOB/CLOB/加密欄位）
- 小表（<100MB），Metadata開銷佔比高
決策依據：`ADMIN_GET_TAB_COMPRESS_INFO` 實測壓縮率與`MON_GET_TABLE` CPU消耗。
打破迷思的核心在於：**以度量代替經驗，以負載驅動架構**。建議建立：
DB2效能調校無銀彈，唯有持續觀測、假設驗證、知識沉澱，方能駕馭龐大資料系統。
