在 DB2 數據庫的日常運維與優化實踐中，許多源於經驗主義或過時文檔的「鐵律」實際上可能成為性能瓶頸的隱形推手。本文梳理了 10 個最具迷惑性的認知誤區，對照官方最佳實踐與實戰經驗給出正確指引，助力 DBA 避開陷阱，釋放數據庫真實性能。
錯誤觀點： 物理模型應 1:1 映射邏輯模型，任何偏離都是設計缺陷。
事實真相： 物理設計的首要目標是性能。為了消除熱點、優化訪問路徑、利用分區並行、減少聯接開銷，適度的反範式化、冗余列、物化視圖、MDC/ITC 表等物理結構調整不僅合理，而且必要。物理設計服務於性能，而非單純映射邏輯。
錯誤觀點： 只用 BP0，DB2 自己會調度最優。
事實真相： 僅在內存極度受限（<10,000 個 4K 頁）且無精力調優時才可退而求其次。生產環境鐵律：除 DB2 目錄表空間外，嚴禁將用戶表空間、索引空間、臨時表空間放入 BP0。 應按訪問模式（隨機/順序）、數據熱度、頁大小劃分專用緩衝池，實現資源隔離與精準預讀。
錯誤觀點： 排序、哈希聯接、物化視圖全是順序寫讀，無需關注隨機 I/O。
事實真相： 工作文件中的頁級隨機活動佔比可達 3%~10%，極端情況高達 45%。DSNDB07 必須配置多個容器分布於不同物理磁盤/RAID 組，並分配足夠緩衝池，不能視為純順序負載。
錯誤觀點： 變長列放行末可避免行遷移，提升性能。
事實真相： 這僅在「極少更新、頻繁全表掃描」的只讀場景下成立（可減少 CPU 解析開銷）。
反之，若表頻繁 UPDATE、或啟用行壓縮，行尾放置反而會導致行長度變化引發頁分裂、重組開銷劇增。 原則：高頻更新表的 VARCHAR 應放行尾；唯讀/低更新表可按訪問頻序排列列序。
錯誤觀點： 伪代碼邏輯順序即最優執行順序。
事實真相： 邏輯流程圖不考慮索引覆蓋、聯接順序、謂詞下推、並行度等物理層面因素。OLTP 核心交易路徑的 SQL 必須經過訪問計劃審查，必要時使用優化器提示或重寫 SQL 結構（如提前過濾、拆分大事務），而非照搬業務邏輯順序。
錯誤觀點： SQL 只負責增刪改查，複雜業務規則放應用層。
事實真相： SQL 是圖靈完備的集合運算語言，擁有窗口函數、遞歸 CTE、MERGE、JSON/XML 處理等豐富能力。真正的問題在於開發者將 SQL 當作「行級 I/O 接口」而非「集合處理器」使用——單筆循環調用、客戶端過濾、多次往返網絡，才是性能殺手。能用單條 SQL 完成的集合運算，絕不拆到應用層迭代。
錯誤觀點： 建立外鍵約束既保證數據質量又省去應用層校驗代碼。
事實真相： RI 的語義是「強制父子業務實體關係」，而非「編輯有效值清單的快捷方式」。
濫用 RI 會導致： 大量鎖爭用、載入/刪除性能劣化、Schema 演進困難、跨庫遷移受阻。
正確做法： 真正的父子關係（訂單-明細、客戶-賬戶）用 RI；代碼表、字典表採用應用層緩存校驗或觸發器/檢查約束替代。
錯誤觀點： 索引越多寫入越慢，所以要極度克制。
事實真相： 索引數量應由 查詢工作負載的訪問路徑多樣性 決定。OLTP 系統單表 5~10 個索引屬常態；關鍵在於：
① 定期運行 RUNSTATS 並收集索引掃描統計；
② 利用 SYSCAT.INDEXES 與 MON_GET_INDEX_USAGE 識別從未被使用的索引並刪除；
③ 採用包含列避免回表、利用索引鍵順序滿足 ORDER BY/GROUP BY。
錯誤觀點： NPI 會導致跨分區掃描、維護開銷大、影響分區獨立性。
事實真相： NPI 是支援 全表唯一性約束、跨分區高效點查、避免全分區掃描 的關鍵工具。其維護開銷可通過以下方式控制：
① 僅在業務真正需要全局唯一或跨分區點查時建立；
② 利用 ALTER INDEX ... CLEANUP 定期整理；
③ 結合分區裁剪，優化器會自動判斷是否走 NPI。一概禁止 NPI 會迫使關鍵查詢退化為全表掃描，得不償失。
錯誤觀點： 行數超過某閾值（如億級）就必須分區，否則性能必然下降。
事實真相： 分區的核心價值在於 數據生命周期管理（滾動清除歷史數據）、分區裁剪減少掃描範圍、並行裝載/備份/重組。
若表僅為大但無明顯的時間/範圍維度、查詢多為全表聚合、無滾動清理需求，不分區反而因元數據開銷更小、優化器搜索空間更簡單而表現更好。實戰中千萬行甚至億級非分區表在合理索引下支撐高並發 OLTP 並不罕見。
DB2 性能優化沒有銀彈，只有基於工作負載特徵、硬體資源、業務 SLA 的持續度量與權衡。打破這 10 大認知誤區，不代表否定最佳實踐，而是提醒我們：每一條「鐵律」背後都有其適用邊界，盲目遵守比不知其然更危險。 讓數據說話，用訪問計劃驅動決策，才是 DBA 進階的必由之路。
