資料庫效能調優充滿「大家都以為」的錯誤認知。本文盤點十大經典迷思，對照實戰真相，助您避開認知陷阱，做基於事實的優化決策。
| # | 迷思 | 真相 |
|---|---|---|
| 1 | DB2 預設值就是最好的 | 預設值隨版本變動，非最優。例：CURRENTDATA 綁定參數需依隔離級別調整。 |
| 2 | WHERE 條件不能用否定邏輯 | 單一否定謂詞可能觸發表空間掃描，但多數情況下 DB2 引擎內部過濾更高效，無需人為改寫。 |
| 3 | 只靠 EXPLAIN 判斷存取路徑好壞 | EXPLAIN 不顯示查詢塊執行順序、一/二階段謂詞、塊執行耗時。需結合 Visual Explain、監控指標、實測綜合判斷。 |
| 4 | EDM Pool 不要太大以免分頁 | EDM Pool 透過分頁 (擴展儲存) 提升效能，過小反而導致頻繁結構重建。適度放大通常有益。 |
| 5 | Extent (區段) 大小不影響其他 | 新型磁碟快取控制器已降低影響，但仍有額外檢查開銷。大表順序掃描受益大 Extent，隨機存取宜小。 |
| 6 | 關聯分區 (Range Partitioning) 在 DB2 不實用 | 早已廣泛用於 DSS/BI/市場系統，單一程序可多次利用，極大提升掃描裁剪效率。 |
| 7 | 所有套件綁定兩個計劃：批次與線上 | 過度簡化，忽略並發、隔離級別、綁定選項差異，實務需按應用模組細分計劃。 |
| 8 | Uncommitted Read (UR) 是壞事 | UR 是強大效能增強手段，適用於報表、查詢、唯讀場景，可大幅減少鎖爭用，遠非洪水猛獸。 |
| 9 | 無 Timeout/Deadlock 即無鎖問題 | 鎖等待時間才是關鍵指標。無死鎖不代表無爭用，長時間鎖等待同樣拖垮回應時間，需主動監控 LOCK_WAIT_TIME。 |
| 10 | ESA 壓縮總是好的 | 壓縮省空間但增 CPU。OLTP 高頻更新表壓縮可能得不償失。需逐表評估讀寫比、CPU 預算再決定。 |
打破迷思，回歸數據，方能行穩致遠。
