| # | 迷思 | 真相 |
|---|---|---|
| 1 | 邏輯=物理 100% 映射 | 效能優化需適度偏離（分區、MQT、非正規化） |
| 2 | 全塞 BP0 讓 DB2 管 | 嚴禁使用者物件進 BP0；依存取模式規劃多緩衝池 |
| 3 | DSNDB07 純循序 | 工作檔 3%~45% 隨機 I/O |
| 4 | VARCHAR 必放行尾 | 唯高頻更新表建議；否則增 CPU |
| 5 | 程式遵循邏輯流程 | OLTP 需針對存取路徑優化 |
| 6 | 業務邏輯不在 SQL | SQL 是集合處理器，善用減少網路往返 |
| 7 | 用 RI 代替驗證 | RI 僅用真正父子關聯 |
| 8 | 表最多 1~2 索引 | 依查詢模式建必要索引，寫入可接受無上限 |
| 9 | NPI 禁用於大表 | NPI 對跨分區查詢/唯一性不可或缺 |
| 10 | 大表必分割 | 60 億列可不分割；分割動機應為管理/可用性 |
| 11 | 預設值即最佳 | 關鍵參數 (CURRENTDATA 等) 必須調校 |
| 12 | WHERE 禁否定 | 單純否定可能全掃；混合條件交引擎過濾 |
| 13 | 只看 EXPLAIN | 缺順序/階段/耗時；需配合 Visual Explain+實測 |
| 14 | EDM Pool 勿大 | 適度分頁到擴充儲存反而增效能 |
| 15 | Extent 無影響 | 管理開銷仍存在 |
| 16 | 關聯劃分不用 | BI/星狀模型大量使用 |
| 17 | 套件綁兩計畫 | 現代依模組/版本/隔離級細分 |
| 18 | UR 是壞事 | UR 是低成本高並發利器 |
| 19 | 無逾時/死鎖=無鎖問題 | 鎖等待時間才是關鍵指標 |
| 20 | ESA 壓縮永遠好 | 逐表評估 CPU/IO 權衡 |
**實測、基準、監控、迭代** — 效能調校無銀彈，唯有數據驅動的持續優化。
