2、分区键选择：如何选择合适的分区键、常见分区键类型、分区键对性能的影响

分区键选得好不好，直接决定你的分区方案是「加速器」还是「拖油瓶」。我见过太多团队，分区表建得漂漂亮亮，结果跑起来比单表还慢——十有八九是分区键选错了。

说白了，分区键就是数据分发的「路由器」。它告诉数据库：这条记录该去哪个分区待着。选对了，查询只扫一个分区；选错了，每个分区都得翻一遍。

2.1 分区键的核心原则

我个人习惯，选分区键先问自己三个问题：

1. 查询条件里有没有它？ 分区键必须是你最常用的 WHERE 条件。否则分区裁剪（Partition Pruning）根本用不上。
2. 数据分布够不够均匀？ 别让一个分区撑死，其他分区饿死。
3. 分区数量会不会失控？ 分区太多，元数据管理开销反而会拖垮性能。

举个例子。我在做物联网数据采集时，设备上报时间戳几乎出现在每条查询里。用时间做分区键，天然满足前两条。但要注意——如果按小时分区，一年就是 8760 个分区。嗯，这里要小心。

2.2 常见分区键类型

不同场景下，分区键的选择套路不太一样。我整理了几种常见类型，你对照着看：

分区键类型	典型字段	适用场景	我踩过的坑
时间/日期	create_time、event_ts	日志、监控、交易流水	按天分区太多，改成了按月
地域/区域	city_id、region_code	多租户、地理分布系统	热点城市数据倾斜严重
业务ID	user_id、order_id	用户维度的查询场景	ID 取模后数据分布还行
哈希值	hash(key) % N	均匀打散数据	范围查询基本废了
枚举/状态	status、type	状态机、分类统计	枚举值太少，分区不均衡

2.2.1 时间分区键

这是数据采集系统里最常用的。为什么？因为采集数据天然带时间属性，而且大部分查询都是「查最近 N 小时/天」的数据。

我曾经接手过一个项目，按小时分区存储传感器数据。刚开始数据量不大，跑得挺欢。半年后，分区数飙到 4000+，每次查询都要扫描分区元数据，反而比全表扫描还慢。

2.2.2 哈希分区键

当你找不到天然均匀的字段时，哈希分区是个好选择。比如用户 ID 取模，数据基本能打散。

但有个问题——范围查询基本用不上分区裁剪。你想想看，查「2024-01-01 到 2024-01-07」的数据，如果用 user_id 哈希分区，每个分区都得扫一遍。

-- 错误示范：哈希分区键 + 范围查询
SELECT * FROM sensor_data
WHERE user_id % 16 = 0          -- 只扫一个分区
  AND event_time >= '2024-01-01' -- 但还得扫全分区数据

-- 正确做法：时间作为分区键，user_id 作为二级索引
SELECT * FROM sensor_data
WHERE event_time >= '2024-01-01'
  AND user_id = 12345

2.2.3 业务ID分区键

用户维度的系统，用 user_id 分区很自然。但要注意数据倾斜——大客户的数据量可能是普通用户的几百倍。

我记得有个电商项目，按店铺 ID 分区。双十一那天，头部店铺的分区数据量暴涨，磁盘 IO 直接打满。其他分区闲得发慌，但整体查询还是慢。

2.3 分区键对性能的影响

分区键选错了，性能不升反降。我总结了三个关键影响点：

2.3.1 查询性能：分区裁剪效率

分区裁剪是分区表最大的性能红利。查询时，数据库只扫描匹配的分区，跳过不相关的。

但前提是——查询条件必须包含分区键。如果你的查询条件里没有分区键，数据库只能全分区扫描。那还不如用单表呢。

-- 高效查询：分区裁剪生效
SELECT * FROM sensor_data
WHERE event_date = '2024-01-15'  -- 只扫 1 个分区
  AND device_id = 'A001'

-- 低效查询：分区裁剪失效
SELECT * FROM sensor_data
WHERE device_id = 'A001'         -- 扫所有分区
  AND value > 100

2.3.2 写入性能：数据分布与锁竞争

写入性能取决于数据写入的分布。如果所有写入都集中在同一个分区，那就是「单点写入」，并发能力大打折扣。

我做过一个测试：用时间分区键，每秒 10 万条写入，全部落在当前小时分区。结果那个分区的写入延迟从 2ms 飙升到 200ms。改成按天分区后，写入分散到 24 个分区，延迟降回 3ms。

2.3.3 维护性能：分区管理成本

分区表需要定期维护——添加新分区、删除旧分区、合并小分区。分区键的选择直接影响维护成本。

• 时间分区： 维护简单，可以自动化。按月分区，每月初自动建新分区，删除 6 个月前的旧分区。
• 哈希分区： 扩容麻烦。从 16 个分区扩到 32 个，数据得重新分布，代价很大。
• 业务ID分区： 新增业务线时，可能需要重新评估分区策略。

2.4 分区键选择的决策流程

说了这么多，到底怎么选？我画了一张决策图，帮你理清思路：

2.5 实战中的常见误区

最后，分享几个我亲眼见过的翻车案例：

• 误区一：用主键做分区键。 主键通常是自增 ID，查询很少用它做条件。分区裁剪用不上，等于白分区。
• 误区二：分区键字段太细。 比如按设备 ID 分区，设备数量几百万，分区数也跟着爆炸。元数据管理先扛不住。
• 误区三：忽略数据生命周期。 采集系统的数据通常有时效性。如果分区键跟时间无关，删除过期数据时得全表扫描，效率极低。