
> 十五年数据库相关经验，做过 DBA、架构师、技术顾问。不求"颠覆"，只求"靠谱"。

---

一张表到了几千万甚至上亿行，即使有索引，查询也开始变慢。插入变慢、更新变慢、DDL 操作几乎不可能。

很多人第一反应是"分库分表"。但分库分表不是第一步。在分库分表之前，有一个更轻量的方案：分区表。

分区表不需要中间件，不需要改应用代码，数据库原生支持。一张 5 亿行的表，按月分区后，每个分区只有几千万行，查询只扫目标分区，性能大幅提升。DDL 操作（比如删除过期数据）变成 drop 一个分区，秒级完成。

今天把分区表的完整实战讲清楚。什么时候该分区、范围/列表/hash 分区怎么选、怎么建、怎么维护、踩了什么坑。

---

## 01 什么时候该用分区表

不是所有大表都需要分区。分区表有明确的适用场景。

### 适合分区的场景

**场景一：数据按时间持续增长，查询通常带时间条件。**

日志表、订单表、流水表——数据按天/月增长，查询通常是"查某个月的数据"。这种表按时间范围分区，查询自动只扫目标分区（分区裁剪），性能提升明显。

**场景二：需要定期清理历史数据。**

保留近 12 个月数据，更早的删除。如果没有分区，DELETE 几千万行数据要很久，还会产生大量 WAL 日志和碎片。有了分区，直接 DROP 一个分区，秒级完成。

**场景三：大表 DDL 操作困难。**

给一张 3 亿行的表加索引，可能要跑几个小时，期间锁表。分区后，每个分区单独建索引，可以并行操作，不影响其他分区。

### 不适合分区的场景

**场景一：数据量不大。** 几百万行的表，分区只会增加复杂度，不会提升性能。

**场景二：查询条件不包含分区键。** 如果大部分查询都不带分区键（比如按时间分区的表，查询却按用户 ID），分区裁剪无法生效，反而多了一层管理开销。

**场景三：跨分区关联查询多。** 两个分区表 JOIN，如果分区键不一致，会产生跨分区笛卡尔积，性能反而下降。

---

## 02 三种分区策略：怎么选

分区策略的核心是"数据怎么分"。分错了，性能不升反降。

### 范围分区（Range Partitioning）

按某个列的值的范围分配数据。最常见的是按时间范围分区。

```sql
-- 按月份范围分区
CREATE TABLE orders (
    id BIGINT,
    user_id INT,
    amount DECIMAL(10,2),
    order_date DATE,
    status VARCHAR(20)
) PARTITION BY RANGE (order_date);

-- 创建分区
CREATE TABLE orders_2025_01 PARTITION OF orders
    FOR VALUES FROM ('2025-01-01') TO ('2025-02-01');
CREATE TABLE orders_2025_02 PARTITION OF orders
    FOR VALUES FROM ('2025-02-01') TO ('2025-03-01');
CREATE TABLE orders_2025_03 PARTITION OF orders
    FOR VALUES FROM ('2025-03-01') TO ('2025-04-01');
```

查询带 `order_date` 条件时，优化器自动只扫目标分区：

```sql
-- 只扫 orders_2025_02 一个分区
EXPLAIN SELECT * FROM orders WHERE order_date = '2025-02-15';
```

**适用场景**：时间序列数据、日志、订单、流水——查询条件通常带时间范围。

### 列表分区（List Partitioning）

按某个列的离散值分配数据。

```sql
-- 按地区列表分区
CREATE TABLE users (
    id BIGINT,
    name VARCHAR(100),
    region VARCHAR(20),
    created_at TIMESTAMP
) PARTITION BY LIST (region);

CREATE TABLE users_east PARTITION OF users
    FOR VALUES IN ('北京', '上海', '广州', '深圳');
CREATE TABLE users_central PARTITION OF users
    FOR VALUES IN ('武汉', '长沙', '郑州', '合肥');
CREATE TABLE users_west PARTITION OF users
    FOR VALUES IN ('成都', '重庆', '西安', '昆明');
```

**适用场景**：数据按地区、类型、状态等离散值分布，查询条件通常包含这些字段。

### Hash 分区

对分区键做哈希运算，均匀分布到各个分区。

```sql
-- 按 user_id 做 hash 分区，分成 4 个分区
CREATE TABLE events (
    id BIGINT,
    user_id INT,
    event_type VARCHAR(50),
    created_at TIMESTAMP
) PARTITION BY HASH (user_id);

CREATE TABLE events_0 PARTITION OF events FOR VALUES WITH (MODULUS 4, REMAINDER 0);
CREATE TABLE events_1 PARTITION OF events FOR VALUES WITH (MODULUS 4, REMAINDER 1);
CREATE TABLE events_2 PARTITION OF events FOR VALUES WITH (MODULUS 4, REMAINDER 2);
CREATE TABLE events_3 PARTITION OF events FOR VALUES WITH (MODULUS 4, REMAINDER 3);
```

user_id = 100 会落到哪个分区，由 `100 % 4` 决定。数据均匀分布，没有热点。

**适用场景**：没有明显范围或分类特征的大表，目的是分散数据量，让每个分区大小可控。

> 踩坑提醒：不要为了"看起来高级"选 hash 分区。大多数业务场景更适合范围分区或列表分区，因为查询条件通常带范围或分类。hash 分区适合没有查询模式特征的场景。

---

## 03 分区维护：创建、删除、拆分

分区表建好了不是"一劳永逸"。分区需要持续维护。

### 新增分区

范围分区最常见的维护操作：提前创建未来时间的分区。

```sql
-- 提前创建下个月的分区
CREATE TABLE orders_2025_04 PARTITION OF orders
    FOR VALUES FROM ('2025-04-01') TO ('2025-05-01');
```

**建议在分区过期前至少提前一个月创建。** 比如 3 月底要创建 4 月的分区，不要等到 4 月 1 号才建。如果写入数据时发现分区不存在，会直接报错。

PostgreSQL 支持默认分区（DEFAULT partition），当数据不匹配任何已有分区时落入默认分区。但默认分区不是好的长期方案——它会逐渐变大，而且不能直接拆分成独立分区（需要重建）。所以还是提前建好。

### 删除过期分区

```sql
-- 删除 12 个月前的分区
ALTER TABLE orders DETACH PARTITION orders_2024_01;
DROP TABLE orders_2024_01;
```

用 DETACH 先解绑，再 DROP。DETACH 是 DDL 操作，很快。DROP 删除实际数据，也很快（比 DELETE 快几个数量级）。

> 踩坑提醒：DROP 之前先确认分区里的数据不再需要。可以用 pg_dump 导出做归档，或者直接 COPY 到归档表。

### 分区拆分

如果一个分区数据量太大，可以拆分成更小的分区。但 PostgreSQL/KES 不支持直接 SPLIT 分区，需要手动操作：

```sql
-- 假设 orders_2025_02 数据量太大，想按周拆分
-- 1. 创建新的周分区
CREATE TABLE orders_2025_02_w1 PARTITION OF orders
    FOR VALUES FROM ('2025-02-01') TO ('2025-02-08');
-- ... 创建 w2, w3, w4

-- 2. 先把月分区从主表解绑
ALTER TABLE orders DETACH PARTITION orders_2025_02;

-- 3. 把数据迁移到周分区
INSERT INTO orders SELECT * FROM orders_2025_02;

-- 4. 删除旧的月分区
DROP TABLE orders_2025_02;
```

这个过程需要停机窗口，因为中间有一段时间数据不在分区结构里。如果数据量大，用 pg_dump + pg_restore 或者逻辑导出导入。

---

## 04 分区表的常见坑

### 坑一：分区键选择不当

选了分区键，但大部分查询条件不带分区键。分区裁剪无法生效，查询扫了所有分区，性能没有提升反而下降。

**怎么避免**：先分析查询模式。80% 以上的查询是否都包含分区键？如果不是，换分区策略或者不分。

### 坑二：全局索引缺失

分区表的主键和唯一约束必须包含分区键。如果你的业务需要按非分区键做唯一校验，必须单独处理。

```sql
-- 主键必须包含分区键
CREATE TABLE orders (
    id BIGINT,
    order_date DATE,
    PRIMARY KEY (id, order_date)  -- 必须包含 order_date
) PARTITION BY RANGE (order_date);
```

如果 `id` 本身需要全局唯一（不含分区键），分区表不支持。这是分区表的固有限制。

### 坑三：跨分区 JOIN 性能差

两个分区表 JOIN，如果分区键不一致，会产生跨分区笛卡尔积。

```sql
-- orders 按 order_date 分区，order_items 按 item_date 分区
SELECT * FROM orders o JOIN order_items oi ON o.id = oi.order_id;
-- 如果 order_date 和 item_date 不一致，会扫所有分区组合
```

**解法**：关联的两个表用相同的分区键，或者把小表广播到所有分区（绑定集合策略）。

### 坑四：忘记创建未来分区

范围分区如果不提前创建未来分区，写入新数据时直接报错。

**解法**：用定时任务自动创建未来分区：

```sql
-- 每月 25 号创建下个月的分区
SELECT cron.schedule('create_next_month_partition',
    '0 0 25 * *',
    $$
    -- 动态创建下个月分区（逻辑需按实际表结构调整）
    $$
);
```

或者用应用层脚本定期检查分区是否存在，不存在就创建。

---

## 对比：分区表 vs 分库分表 vs 单表优化

| 维度 | 单表优化 | 分区表 | 分库分表 |
|------|---------|--------|---------|
| 数据量上限 | 几千万行 | 几亿行 | 理论无上限 |
| 查询性能 | 依赖索引 | 分区裁剪 + 索引 | 路由到目标分片 |
| 写入性能 | 单表写入 | 单分区写入 | 多分片并行写入 |
| 运维复杂度 | 低 | 中 | 高 |
| 应用改造 | 不需要 | 不需要 | 需要 |
| DDL 操作 | 慢（全表锁） | 快（分区级） | 分片级 |
| 历史数据清理 | DELETE（慢） | DROP 分区（快） | 清理分片 |

---

## 决策框架：按数据量和查询模式选择方案

| 数据量 | 查询模式 | 推荐方案 | 说明 |
|--------|---------|---------|------|
| < 1000 万行 | 任意 | 单表 + 索引 | 分区只会增加复杂度 |
| 1000 万 - 1 亿行 | 查询带范围条件 | 范围分区 | 分区裁剪效果好 |
| 1000 万 - 1 亿行 | 查询带分类条件 | 列表分区 | 按分类路由 |
| 1000 万 - 1 亿行 | 查询无固定模式 | Hash 分区 | 均匀分散数据 |
| 1 亿 - 5 亿行 | 查询带范围条件 | 范围分区 + 二级索引 | 分区裁剪 + 索引 |
| > 5 亿行 | 单表扛不住 | 分库分表 | 单机到达极限 |

---

## 深度分析：为什么分区表经常被误用

分区表好用，但误用的情况很常见。

**第一，为了分区而分区。** 数据量不大的时候就上了分区，以为"早晚用得上"。结果分区增加了管理复杂度，性能没有明显提升。分区是"数据量大到单表性能下降"时的方案，不是预防性方案。

**第二，分区键和业务查询不匹配。** 按时间分区，但大部分查询按用户 ID 查。分区裁剪不生效，查一次扫所有分区，比不分还慢。分区键的选择必须基于实际查询模式，不是基于"哪个字段数据量大"。

**第三，建了分区就不管了。** 分区表需要持续维护——提前创建未来分区、定期删除过期分区、监控分区大小。建完就不管，过几个月分区满了写入报错，或者过期数据堆积占满磁盘。

分区表的核心原则是：查询模式决定分区策略，数据量决定分区时机，持续维护决定分区效果。

---

## 总结

分区表是单机大数据量的最优解——不需要中间件、不需要改应用代码、数据库原生支持。

范围分区适合时间序列数据，列表分区适合分类数据，hash 分区适合无固定查询模式的大表。分区键选择必须基于实际查询模式，不是凭感觉。

分区表不是分库分表的替代品，是分库分表的前一步。能分区解决的不用分库分表，单机扛不住了再走分库分表的路径。

维护分区是持续工作：提前创建未来分区、定期清理过期分区、监控分区大小。建完就不管，分区表会变成定时炸弹。

后续我会继续分享**主备切换与故障转移、锁排查**这些话题，跟着我一篇篇学，数据库这块就没问题了。

有问题评论区见。

---

*十五年数据库领域老炮。关注我，一起把数据库这件事搞明白。*


十五年数据库相关经验，做过 DBA、架构师、技术顾问。不求"颠覆"，只求"靠谱"。

数据库分区表完整指南：从创建到维护的踩坑总结

一张表到了几千万甚至上亿行，先考虑分区表再考虑分库分表。本文拆解范围分区、列表分区、hash 分区的适用场景和建表方法，总结四大常见坑（分区键不当、全局索引缺失、跨分区 JOIN、忘记创建未来分区），附分区表 vs 分库分表 vs 单表优化对比。

编程语言

大表性能优化首选方案：分区表实战解析。5亿行数据按月分区后，查询性能大幅提升，删除过期数据秒级完成。详解范围、列表、Hash三种分区策略选择，分区键设计关键，以及分区维护、常见踩坑与分库分表对比决策框架，适合DBA和架构师参考。

数据迁移

代码解释

PostgreSQL

中间件

数据库

大数据

路由

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

数据库分区表完整指南：从创建到维护的踩坑总结-腾讯云开发者社区-腾讯云

数据库分区表完整指南：从创建到维护的踩坑总结

数据库分区表完整指南：从创建到维护的踩坑总结

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐