| # | 常見迷思 | 實務真相 |
|---|---|---|
| 1 | 邏輯設計必須 100% 對應物理設計 | 為效能可適度偏離邏輯模型（分區、MQT、非正規化） |
| 2 | 所有物件放入 BP0 讓 DB2 自管 | 除目錄表外，嚴禁 使用者物件進 BP0；依存取模式規劃多缓冲池 |
| 3 | DSNDB07 100% 循序存取 | 工作檔案含 3%~45% 隨機 I/O |
| 4 | VARCHAR 必須置於行尾 | 唯有「高頻更新、低頻讀取」表才建議置尾；否則增加 CPU |
| 5 | 程式碼應遵循邏輯流程編寫 | OLTP 需針對存取路徑優化，偽碼邏輯常導致全表掃描 |
| 6 | 大多數業務邏輯不在 SQL 中處理 | SQL 是集合處理器，善用可大幅減少網路往返與應用層邏輯 |
| 7 | 用 RI 替代應用層驗證 | RI 僅用於真正父子關聯；驗證邏輯仍屬應用責任 |
| 8 | 表最多 1~2 個索引 | 依查詢模式建立必要索引，寫入負擔可接受範圍內不設上限 |
| 9 | 非分割索引 (NPI) 禁止用於大表 | NPI 對跨分區查詢、唯一性約束不可或缺 |
| 10 | 大表必須分割 | 60 億列以上仍可不分割；分割動機應為管理/可用性而非單純效能 |
| 11 | DB2 預設值即最佳 | 預設值隨版本變動，關鍵參數（如 CURRENTDATA）必須依負載調校 |
| 12 | WHERE 條件禁用否定邏輯 | 僅單純否定謂詞可能觸發表掃；混合條件下交由引擎過濾更佳 |
| 13 | 只看 EXPLAIN 判斷存取路徑好壞 | EXPLAIN 缺少執行順序、階段謂詞、實際耗時；需配合 Visual Explain + 實測 |
| 14 | EDM Pool 勿過大避免分頁 | 適度分頁到擴充儲存反而提升效能；過小導致結構重建開銷更大 |
| 15 | Extent 大小不影響其他 | 雖 SAN/ESS 緩衝影響，Extent 管理仍有額外 CPU/元資料開銷 |
| 16 | 關聯劃分不在 DB2 使用 | BI/市場分析系統大量使用關聯劃分（星狀/雪花模型） |
| 17 | 所有套件綁定到批次/線上兩個計畫 | 現代套件管理應依應用模組、版本、隔離級細分計畫 |
| 18 | Uncommitted Read (UR) 是壞事 | UR 是低成本高並發利器，適用唯讀報表、日誌查詢等可容忍髒讀場景 |
| 19 | 無逾時/死鎖即無鎖問題 | 鎖等待時間才是關鍵指標；無死鎖不代表無效能損耗 |
| 20 | ESA 壓縮永遠有益 | 壓縮需逐表評估 CPU/IO 權衡；高頻更新表可能得不償失 |
效能調校無銀彈，**實測、基準、監控、迭代** 四字訣才是正道。
