DB2 數據庫應用系統性能優化深度實戰：設計、查詢、並發三大維度

一、數據庫設計優化

1. 深度理解業務 — 優化的前提

不懂業務的 DBA 只能做表面調優。熟悉業務流程、數據流向、核心查詢模式，才能在規範化與性能間做正確取捨。

2. 規範化與反規範化的平衡

• 規範化優勢： 減少冗余、窄行、單表掃描快。
• 規範化劣勢： 多表連接、CPU/I/O 開銷大。
• 實戰策略： 核心大表（如訂單明細表 OrderDetail）適度冗余常用維度字段（投遞員、收款員、物品、價格策略、客戶信息），避免百萬級大表連接 5+ 維表，查詢從小時級降至秒級。以空間換時間，前提是保證邏輯一致性（觸發器/ETL 同步冗余列）。

3. 數據分區（條帶化）

• 水平分區： 按日期/地區/部門切分，熱數據與冷數據分離，分區剪枝大幅減少掃描量。
• 垂直分區： 將寬表拆分為「常用窄表」+「不常用寬表」，主表僅保留高頻列，掃描更少頁。

4. 數據類型選擇

• 大文本用 BLOB/CLOB 而非巨大 VARCHAR，LOB 存指針，數據可外置，減緩表膨脹。
• 主鍵優先用整型（INT/BIGINT），比較/連接/索引效率遠高於字符型。
• 善用 UDT（用戶定義類型）統一業務語義與約束。

5. 索引設計原則

• 連接鍵（非外鍵）建索引。
• GROUP BY/ORDER BY 高頻列建索引，利用索引順序避免排序。
• 高選擇性（唯一值多）列建索引；低選擇性（如性別、狀態）不建或用組合索引。
• 多列排序/過濾組合索引（COMPOUND INDEX），列順序遵循「等值優先、範圍其次、排序最後」。
• 權衡：索引加速讀、拖慢寫、佔空間、增維護成本。

二、查詢優化核心技巧

1. 避免/簡化排序

能用索引順序輸出時避免排序。不可避免時：縮小排序列、限制排序行數（FETCH FIRST）、避免 DISTINCT（產生工作表+排序）。

2. 主鍵用整型

字符主鍵比較開銷大，大數據量下差異顯著。

3. 子查詢轉連接

相關子查詢每行外層掃描一次內層，開銷指數級。改寫為 JOIN 或 EXISTS，優化器更易生成哈希/合併連接計劃。

4. 通配符優化

LIKE 'M%' 可走索引；LIKE '%M%' 或 LIKE 'M___' 導致全表掃描。改用範圍查詢：WHERE col >= 'M' AND col < 'N'。

5. 慎用 DISTINCT

產生臨時表+排序+去重，開銷大。業務允許時用 GROUP BY 或應用層去重。

6. 避免負邏輯

!=、<>、NOT IN、NOT EXISTS 多導致全表掃描。改用正向邏輯或 LEFT JOIN ... WHERE right.key IS NULL。

7. 減少臨時表

磁盤臨時表 I/O 重、分布式環境下同步成本高。優先用 WITH (CTE)、內聯視圖、派生表在內存完成中間結果。

8. 善用存儲過程

復雜邏輯封裝為 SP，首次編譯生成優化計劃緩存，後續調用省去解析/優化開銷，減少網絡往返。配合 Query Patroller 對比計劃代價，Performance Monitor 監控 I/O/排序/鎖等待。

三、並發與鎖控制

• 鎖粒度權衡： 表鎖開銷小、並發低；行鎖開銷大、並發高。大批量維護窗口用表鎖，線上業務用行鎖。
• 避免長事務持有表鎖： 導致全系統阻塞。複雜查詢改用視圖/只讀副本/物化視圖隔離。
• 視圖解決鎖衝突： 視圖不持有底表鎖，可作為只讀訪問層，兼顧並發與性能。

總結

性能優化是系統工程：設計定上限、查詢定下限、並發定穩定性。引入 RUNSTATS 自動化、REORG 定期整理、EXPLAIN 計劃審查機制，建立「開發自審→DBA 複核→上線觀測」閉環，才能持續應對數據增長帶來的挑戰。