DB2 9.7 分區索引新特性：大型數據倉庫性能與維護的雙重飛躍

背景：分區表的索引痛點

DB2 9 引入表分區（Range Partitioning），數據按列值範圍分散至多個數據分區，便於 ATTACH/DETACH PARTITION 秒級轉入轉出。但索引仍為非分區（全局索引），鍵值指向所有分區，導致：

• 索引隨數據增長龐大，查詢/維護開銷大
• ATTACH 後需為新分區建索引，DETACH 前需清理鍵值，耗時長、影響可用性

分區索引：索引亦分區

DB2 9.7 引入 Partitioned Index（本地索引），每個索引分區僅針對對應數據分區建立鍵值。系統/用戶索引均可分區。非分區索引更名為 Global Index。

創建與存放規則

表級與分區級 INDEX IN 子句

CREATE TABLE datapartT (a INT, b INT)
  IN TbspT INDEX IN TbspX
  PARTITION BY (a, b)
  ( PARTITION Part0 STARTING (0,0) ENDING (0,10) IN TbspD,
    PARTITION Part1 ENDING (20,20) INDEX IN TbspY,
    PARTITION Part2 ENDING (40,40) INDEX IN TbspW,
    PARTITION Part3 STARTING (100,100) ENDING (150,150) INDEX IN TbspW,
    PARTITION Part4 ENDING (200,200) );

• 表級 INDEX IN TbspX：非分區索引默認存放處
• 分區級 INDEX IN TbspY：該分區的所有分區索引分區存放處
• 無分區級 INDEX IN → 分區索引分區與數據分區同表空間

創建索引語法

CREATE INDEX purpleidx ON datapartT(a,b) PARTITIONED;
CREATE INDEX greenidx ON datapartT(b) PARTITIONED;
CREATE INDEX blueidx ON datapartT(a) NOT PARTITIONED;  -- 全局索引

• 默認創建分區索引（不指定 PARTITIONED/NOT PARTITIONED 時）
• 分區索引不可在創建時指定 IN tablespace，存放位置由表定義決定

元數據查詢：識別與定位分區索引

DESCRIBE INDEXES

db2 describe indexes for table datapartt
-- Index partitioning 列：P=分區索引, N=非分區索引

目錄表深度定位

• SYSCAT.INDEXES：分區索引顯示邏輯 ID（TBSPACEID=32768, INDEX_OBJECTID=65530）
• SYSCAT.DATAPARTITIONS：每個數據分區的物理 OBJECTID/TBSPACEID
• SYSCAT.INDEXPARTITIONS（V9.7 新增）：每個索引分區的物理 INDPARTITIONOBJECTID/INDPARTITIONTBSPACEID，同一數據分區下的所有分區索引分區共享一個物理索引對象

非分區索引遷移至分區索引策略

1. 創建同名定義的分區索引（允許同列上同時存在分區/非分區索引）
2. 構建期間原非分區索引仍可用
3. 新索引就緒後 DROP 舊索引
4. RENAME INDEX new_name TO old_name 恢復原名

性能飛躍：Roll-in/Roll-out 秒級完成

全局索引模式（V9.7 前）

• ATTACH：需掃描新數據為所有全局索引建鍵值
• DETACH：需從所有全局索引刪除舊鍵值
• 大索引維護成瓶頸

分區索引模式（V9.7）

• ATTACH：源表索引直接成為目標表新索引分區，無數據移動、無索引重建，僅需 SET INTEGRITY 驗證
• DETACH：索引分區直接轉為新表索引
• 極少開銷，極短時間完成

仍需維護的例外場景

• 目標表有分區索引但源表無對應定義
• 源目索引定義不一致
• 目標表混合存在分區與非分區索引

總結

分區索引將索引結構與數據分區對齊，徹底消除大表分區操作時的索引維護瓶頸，為數據倉庫、BI 系統帶來數量級性能提升。升級至 V9.7 後，建議對核心大表逐步遷移至分區索引架構。