3、静态分区策略：基于范围的分区、基于列表的分区、基于哈希的分区、静态分区的优缺点

静态分区，说白了就是在建表的时候就把分区规则定死。数据进来以后，系统根据你定的规则，把数据扔到对应的分区里去。这个策略很古老，但至今仍然大量使用。为什么？因为它简单、可控、性能可预期。

我个人习惯把静态分区比作「提前分好类的快递柜」——你事先规划好每个格子放什么类型的包裹，快递员来了直接对号入座。今天我们就来拆解三种最常见的静态分区策略，以及它们各自的适用场景。

3.1 基于范围的分区（Range Partitioning）

这是最直观的一种分区方式。按照某个列的取值范围，把数据切分成不同的区间。每个区间就是一个独立的分区。

举个例子，假设我们有一张订单表，按订单日期分区：

CREATE TABLE orders (
    order_id INT,
    customer_id INT,
    order_date DATE,
    amount DECIMAL(10,2)
)
PARTITION BY RANGE (YEAR(order_date)) (
    PARTITION p_2021 VALUES LESS THAN (2022),
    PARTITION p_2022 VALUES LESS THAN (2023),
    PARTITION p_2023 VALUES LESS THAN (2024),
    PARTITION p_future VALUES LESS THAN MAXVALUE
);

这里要注意几个关键点：

• 边界值定义要清晰——每个分区定义的是「小于某个值」的范围，而不是「小于等于」。上面 p_2021 包含的是 2021 年全年的数据，不包含 2022 年的。
• 必须有一个兜底分区——我见过不少新手忘了加 MAXVALUE 分区，结果 2024 年的数据插入时报错。嗯，这个坑我踩过。
• 分区键的选择很关键——通常选日期、数字 ID 这类有自然顺序的列。你想想看，如果用字符串做范围分区，排序规则和边界定义会变得很别扭。

3.2 基于列表的分区（List Partitioning）

列表分区跟范围分区有点像，但它的分区依据不是连续的区间，而是离散的枚举值。说白了，就是「你列一个清单，属于这个清单的数据进这个分区」。

看个例子：

CREATE TABLE customers (
    customer_id INT,
    name VARCHAR(50),
    region VARCHAR(20),
    signup_date DATE
)
PARTITION BY LIST (region) (
    PARTITION p_north VALUES IN ('北京', '天津', '河北', '山西'),
    PARTITION p_south VALUES IN ('广东', '广西', '海南', '福建'),
    PARTITION p_east VALUES IN ('上海', '江苏', '浙江', '安徽'),
    PARTITION p_other VALUES IN (DEFAULT)
);

列表分区有几个特点：

• 适合按类别、地域、状态等离散属性分区——比如按省份、按产品类别、按订单状态。
• 必须处理「未匹配」的情况——上面例子里的 DEFAULT 分区就是用来兜底的。如果不加 DEFAULT，插入一个不在列表里的值会直接报错。
• 列表值不能重叠——同一个值不能出现在两个分区的 IN 列表里，这是硬性约束。

3.3 基于哈希的分区（Hash Partitioning）

哈希分区跟前面两种完全不同。它不关心数据的业务含义，而是对分区键做哈希计算，然后根据哈希值模分区数，决定数据落到哪个分区。

代码示例：

CREATE TABLE user_sessions (
    session_id VARCHAR(64),
    user_id INT,
    login_time TIMESTAMP,
    device_type VARCHAR(20)
)
PARTITION BY HASH (user_id)
PARTITIONS 8;

哈希分区的核心逻辑：

• 数据均匀分布——只要分区键的基数够大，哈希函数能把数据相对均匀地打散到各个分区。这是它最大的优势。
• 分区数通常是 2 的幂——比如 2、4、8、16。为什么？因为很多哈希算法在模 2 的幂时性能更好，而且后续扩容时数据迁移量可控。
• 不支持范围查询剪枝——这是哈希分区最大的软肋。你查 user_id 在 1000 到 2000 之间的数据，系统不知道这些数据在哪个分区，只能全分区扫描。

3.4 三种策略的对比

为了让你看得更清楚，我把三种策略的核心差异整理成了一张表：

对比维度	范围分区	列表分区	哈希分区
分区依据	连续区间	离散枚举值	哈希值模运算
数据分布	可能倾斜	可能倾斜	相对均匀
范围查询剪枝	✅ 支持	❌ 不支持	❌ 不支持
点查询剪枝	✅ 支持	✅ 支持	✅ 支持
分区管理	容易（可增删区间）	中等（需维护列表）	困难（扩容需重哈希）
典型场景	时序数据、日志	地域、类别	用户ID、会话ID

3.5 静态分区的优缺点

聊完了三种具体策略，我们来总结一下静态分区这个「家族」的整体优缺点。

优点

• 查询性能可预期——分区剪枝是静态分区最大的价值。你只要知道查询条件里的分区键值，就能精确知道要扫描哪些分区。性能是稳定的，不会因为数据量增长而突然变慢。
• 管理操作高效——删除一个分区比逐条删除数据快得多。比如日志表按天分区，要删掉 30 天前的数据，直接 drop 分区就行，比 delete 快几个数量级。
• 实现简单——几乎所有主流数据库都原生支持静态分区，语法统一，学习成本低。
• 适合固定业务模型——如果你的业务分区规则基本不变（比如按年、按月、按地区），静态分区是最省心的选择。

缺点

• 灵活性差——分区规则一旦定下来，修改起来很麻烦。比如你原来按年分区，现在想改成按月分区，需要重建表或者做复杂的分区合并/拆分操作。
• 数据倾斜风险——范围分区和列表分区都可能出现某个分区数据量远大于其他分区的情况。哈希分区虽然能缓解，但如果分区键选择不当（比如用性别这种低基数列），照样会倾斜。
• 扩容成本高——哈希分区要增加分区数时，通常需要重新计算所有数据的位置，涉及大量数据迁移。范围分区相对好一些，但也要考虑边界调整的问题。
• 不适合动态变化的分区规则——如果你的业务分区规则经常变（比如按季度、按周、按自定义时间段），静态分区会让你很痛苦。

3.6 三种策略的选择决策流程

为了帮你快速决策，我画了一张流程图：

3.7 实际项目中的选择建议

说了这么多理论，最后给点实在的建议。我在实际项目中总结了几条经验：

• 时序数据首选范围分区——日志、监控、交易流水这类数据，天然按时间维度查询，范围分区是最佳拍档。我做过一个日活千万级的日志系统，按天分区，查询性能和清理效率都非常理想。
• 多租户场景考虑列表分区——如果你的系统有多个租户或业务线，每个租户的数据需要物理隔离，列表分区按租户 ID 分区是个好选择。但要注意租户数量不能太多（一般建议几十到几百个），否则分区数太多反而影响性能。
• 高并发点查询用哈希分区——用户中心、会话管理这类场景，查询条件通常是用户 ID 或会话 ID，哈希分区能把请求均匀分散到多个分区，避免热点。
• 不要迷信单一策略——有时候复合分区（比如先按范围分区，再在每个范围内按哈希子分区）能兼顾多种需求。但复杂度也会上升，需要权衡。