分区键是DB2分片数据库设计中最关键也最容易踩坑的决策之一。一旦表结构上线、数据量增长到亿级，再想调整分区键就意味着停机导数重建表，代价极高。很多团队在设计阶段随手选了一个主键或者唯一索引列做分区键，结果上线后发现查询频繁跨分区、数据严重倾斜，性能远不如预期。这篇文章就来系统梳理DB2分区键的选择原则，以及不同选择对性能的实际影响。
一、先分清两种分区：DPF分片键与表分区键
讨论分区键选择之前，必须先厘清概念，因为DB2里“分区”这个词至少对应两套机制，它们的键选择逻辑完全不同。
第一套是DPF（Database Partitioning Feature，数据库分区特性），也就是我们常说的MPP分片。数据通过哈希算法打散到多个数据库分区节点上，建表时通过DISTRIBUTED BY子句指定分片键。DPF分片键决定了每一行数据落在哪个物理节点，直接影响并行度和跨分区操作的开销。
第二套是表分区（Table Partitioning），按范围（RANGE）把同一节点内的数据切到不同数据分区，比如按月份切分交易表，通过PARTITION BY RANGE子句指定。表分区键的价值主要在分区消除（Partition Elimination）、快速转入转出（ATTACH/DETACH）和数据生命周期管理。
-- DPF分片键示例：按客户ID哈希分布到各分区节点
CREATE TABLE orders (
order_id BIGINT NOT NULL,
customer_id BIGINT NOT NULL,
order_date DATE NOT NULL,
amount DECIMAL(12,2)
)
DISTRIBUTE BY HASH (customer_id)
IN ts_data;
-- 表分区键示例：按订单日期做范围分区
CREATE TABLE orders_part (
order_id BIGINT NOT NULL,
customer_id BIGINT NOT NULL,
order_date DATE NOT NULL,
amount DECIMAL(12,2)
)
PARTITION BY RANGE (order_date)
(PARTITION p202401 STARTING '2024-01-01' ENDING '2024-02-01' EXCLUSIVE,
PARTITION p202402 STARTING '2024-02-01' ENDING '2024-03-01' EXCLUSIVE,
PARTITION p202403 STARTING '2024-03-01' ENDING '2024-04-01' EXCLUSIVE);
两套机制可以叠加使用：先按customer_id做哈希分片到多个节点，再在每个节点内按order_date做范围分区。这种组合在大型交易系统中非常常见，既保证了分布式并行度，又获得了按时间归档的能力。
二、分区键选择的五大核心原则
1. 数据分布必须均匀，避免倾斜
这是DPF分片键的第一原则。哈希分片依赖哈希函数把键值打散，如果键值本身高度重复或者存在大量NULL，哈希后大量行会集中到少数分区，形成数据倾斜。倾斜的直接后果是并行计算退化为单节点计算，其他分区节点空闲等待，整体响应时间由最重的那个分区决定。
典型的坏选择包括：状态列（只有几个取值）、性别列、类型标志列。这类低基数列即使参与复合键，也几乎起不到打散作用。好的候选是取值丰富且分布自然的列，比如流水号、客户号、散列后的会话ID。判断分布是否均匀，可以直接查询系统目录表统计各分区行数：
-- 查看各分区的行数分布，判断是否倾斜 SELECT DBPARTITIONNUM, COUNT(*) AS row_cnt FROM orders GROUP BY DBPARTITIONNUM ORDER BY row_cnt DESC;
如果最大分区行数与平均值的比值超过1.5，就应该认真考虑换键或增加复合列。
2. 优先覆盖高频Join条件，实现共置Join
DPF环境下最大的性能杀手是跨分区Join。如果两张大表做Join时分区键不一致，优化器只能把其中一张表广播（Broadcast）到所有分区，或者按Join键重新分布（Redistribute），两者都会产生大量内部网络开销。
如果事实表之间经常按customer_id关联，那么让这几张表都用customer_id做分片键，Join时两侧数据天然落在同一分区，可以完整共置（Collocated Join），网络开销为零。这也是星型模型中通常让事实表统一按同一个外键列做分片的原因。当然，这个外键的基数必须足够高，否则回到第一条原则。
3. 尽量让高频查询条件命中分区键，触发分区消除
对表分区而言，分区消除是最核心的收益来源。如果查询条件中带有order_date的范围谓词，优化器能直接跳过无关分区，只扫描少量数据。要让这个机制生效，分区键上的谓词写法也有讲究：必须使用能被优化器静态推导的比较形式，避免在分区键上套函数。
-- 能触发分区消除的写法
SELECT * FROM orders_part
WHERE order_date >= DATE('2024-02-01')
AND order_date < DATE('2024-03-01');
-- 无法触发分区消除的写法：分区键上套了函数
SELECT * FROM orders_part
WHERE YEAR(order_date) = 2024 AND MONTH(order_date) = 2;
第二条语句虽然逻辑等价，但因为分区键出现在函数内部，优化器无法推导出分区范围，只能扫描全部分区。这类隐蔽的写法差异在生产中造成的性能损耗非常常见。
4. 分片键列应尽量参与主键或唯一约束
DB2要求分片键列必须是唯一索引的子集，或者表上没有唯一索引。如果不满足，建表时会直接报错。更深层的原因在于：行按分片键哈希定位，唯一性检查必须能在单个分区内完成，否则唯一约束无法维护。因此在设计分片键时，要同步调整主键定义，比如把主键从order_id改为(order_id, customer_id)的组合。
5. 避免使用经常更新的列
分片键或分区键一旦被UPDATE，行的物理归属就会变化，DB2需要执行删除加插入的内部操作，代价远高于普通更新，还可能引发行迁移和统计信息失真。如果业务上确实存在这类更新，应在设计阶段就把该列排除在候选之外。
三、分区键选择不当的典型性能影响
分区键选错的代价往往在数据量上来之后才集中爆发，下面几个场景值得警惕。
第一个场景是数据倾斜导致的热点。某系统曾用“渠道编号”做分片键，渠道只有20个，而其中线上渠道占了70%的交易量。结果是8个分区节点里，一个节点承担了大部分数据扫描和聚合，其他节点基本闲置，查询耗时随着数据增长线性恶化，硬件投入完全没有换来并行收益。
第二个场景是跨分区聚合的额外开销。在没有命中分区键的GROUP BY查询中，DB2需要两阶段聚合：先在各分区本地聚合，再把中间结果汇总到协调节点做最终聚合。这个流程本身合理，但如果分片键选择得当，让GROUP BY的列与分片键一致，就能直接在各分区完成聚合后汇总，中间结果集会小得多。通过EXPLAIN查看执行计划，观察是否出现PTQ（Parallel Table Queue）以及数据重分布操作，可以直观评估这类开销。
-- 通过解释工具查看执行计划中的分区操作
EXPLAIN PLAN FOR
SELECT customer_id, SUM(amount)
FROM orders
WHERE order_date >= DATE('2024-01-01')
GROUP BY customer_id;
-- 查看是否存在广播或重分布步骤
SELECT * FROM EXPLAIN_OPERATOR
WHERE OPERATOR_TYPE IN ('SHIP','BTQ','DTQ','RETURN');
第三个场景是OLTP小事务退化为跨分区事务。单行按主键查询本应只访问一个分区，但如果分片键与查询条件无关，DB2会把查询路由到所有分区，再等待结果汇总，单次查询延迟从亚毫秒级劣化到几十毫秒。对高并发的点查场景，这种劣化是致命的。
四、验证与调整分区效果的实用手段
分区键设计不能只靠纸面推演，上线前后都要有验证手段。设计阶段可以用db2pd工具查看数据在分区间的物理分布情况，用MON_GET_TABLE监控各分区的行读写热度，确认没有明显倾斜。日常巡检中，重点关注PREFETCH WAIT和分区间的通信等待，如果TPCB风格的查询大量时间花在等待其他分区返回数据，基本可以判定分区键与查询模式不匹配。
如果确实需要更换分片键，DB2提供了重分布的方案，但过程会锁表且耗时与数据量成正比，生产环境必须安排在维护窗口，并提前做好备份。更稳妥的做法是在新表上按正确的键重建，通过LOAD或INSERT SELECT迁移数据，最后用RENAME切换，整个流程可控性更好。
总结一下，分区键选择的本质是让数据分布与查询模式对齐：哈希分片键追求分布均匀和Join共置，范围分区键追求谓词命中和时间管理便利。设计时多花一小时分析真实的查询负载，胜过上线后花几天时间救火。建议在表设计评审中把分区键作为必审项，用真实的SQL样本驱动决策，而不是凭经验拍板。