4. PostgreSQL 分区表实现：声明式分区、继承式分区、分区裁剪机制

分区表这东西，说白了就是把一张大表拆成多张小表。但对外看起来，它还像是一张表。我早年做数据库运维时，遇到过一张表几十亿行，查询慢得让人抓狂。后来上了分区，效果立竿见影。今天咱们就聊聊 PostgreSQL 里分区表的三种核心话题：声明式分区、继承式分区，还有那个让查询变快的分区裁剪。

4.1 声明式分区：PostgreSQL 10 之后的标配

PostgreSQL 10 引入了声明式分区。我个人习惯用这种方式，因为它语法简洁，内核自动管理分区。你只需要告诉数据库「按什么列分、分几块」，剩下的它自己搞定。

举个例子，咱们按订单日期分区：

CREATE TABLE orders (
    order_id bigserial,
    order_date date NOT NULL,
    customer_id int,
    amount numeric
) PARTITION BY RANGE (order_date);

CREATE TABLE orders_2024_q1 PARTITION OF orders
    FOR VALUES FROM ('2024-01-01') TO ('2024-04-01');

CREATE TABLE orders_2024_q2 PARTITION OF orders
    FOR VALUES FROM ('2024-04-01') TO ('2024-07-01');

CREATE TABLE orders_2024_q3 PARTITION OF orders
    FOR VALUES FROM ('2024-07-01') TO ('2024-10-01');

CREATE TABLE orders_2024_q4 PARTITION OF orders
    FOR VALUES FROM ('2024-10-01') TO ('2025-01-01');

嗯，这里要注意：声明式分区支持 RANGE、LIST、HASH 三种策略。RANGE 适合时间或数值范围，LIST 适合枚举值（比如地区），HASH 适合均匀打散数据。

核心优势：声明式分区由内核自动维护分区边界，DDL 操作（如新增分区）只需一条 SQL，不需要手动写触发器或规则。

4.2 继承式分区：老版本的选择

在 PostgreSQL 10 之前，分区只能靠继承来实现。虽然现在有了声明式分区，但继承式分区在某些场景下仍有价值。我在项目中遇到过需要跨版本兼容的情况，老系统用的就是继承式分区。

继承式分区的做法是：先建一张父表，再建多张子表继承它，然后通过触发器或规则把数据路由到正确的子表。

-- 父表
CREATE TABLE orders (
    order_id bigserial,
    order_date date NOT NULL,
    customer_id int,
    amount numeric
);

-- 子表继承
CREATE TABLE orders_2024_q1 () INHERITS (orders);
CREATE TABLE orders_2024_q2 () INHERITS (orders);
CREATE TABLE orders_2024_q3 () INHERITS (orders);
CREATE TABLE orders_2024_q4 () INHERITS (orders);

-- 必须手动加检查约束
ALTER TABLE orders_2024_q1 ADD CONSTRAINT chk_q1
    CHECK (order_date >= '2024-01-01' AND order_date < '2024-04-01');
ALTER TABLE orders_2024_q2 ADD CONSTRAINT chk_q2
    CHECK (order_date >= '2024-04-01' AND order_date < '2024-07-01');
-- ... 以此类推

避坑指南：我曾经接手过一个用继承式分区跑了三年的系统，发现子表上的约束条件写错了范围，导致数据插入了错误的分区。继承式分区没有自动边界校验，全靠 DBA 手写 CHECK 约束，一旦写错，查询结果就会出错。所以，能用声明式分区就别用继承式。

继承式分区和声明式分区的核心差异，我整理了一张表：

对比维度 声明式分区 继承式分区
引入版本 PostgreSQL 10+ PostgreSQL 8.x+
分区定义 PARTITION BY 语法 INHERITS + CHECK 约束
数据路由 内核自动路由 需手动触发器/规则
分区裁剪 原生支持，效率高 依赖约束排除，效率较低
DDL 操作 一条 SQL 搞定 需手动维护多张表
适用场景 新项目首选 老版本兼容、特殊定制

4.3 分区裁剪机制：查询加速的核心

分区裁剪，说白了就是查询时只扫描需要的分区，跳过无关的分区。你想想看，如果一张表有 12 个分区，查询条件只涉及 1 个分区，那扫描量就减少了 90% 以上。

PostgreSQL 的分区裁剪发生在计划阶段。优化器会分析 WHERE 条件，判断哪些分区不满足条件，直接把它们从扫描列表中剔除。

举个例子：

EXPLAIN SELECT * FROM orders WHERE order_date = '2024-05-15';

如果 orders 表按 RANGE 分区，优化器会看到 '2024-05-15' 落在 Q2 分区，于是只扫描 orders_2024_q2，其他分区根本不碰。

小技巧：分区裁剪的效果取决于 WHERE 条件的写法。我建议尽量在分区键上使用等值或范围条件，避免使用函数包裹分区键。比如 WHERE order_date = '2024-05-15' 能裁剪，但 WHERE DATE_TRUNC('month', order_date) = '2024-05-01' 就无法裁剪了。

下面这张图展示了分区裁剪的完整流程：

分区裁剪机制流程图 分区裁剪机制流程图 SQL 查询 解析器 优化器 分区裁剪判断 匹配分区（扫描） 不匹配分区（跳过） 返回结果集 分区键条件决定裁剪效果

从图上可以看得很清楚：查询进来后，优化器先做分区裁剪判断，只扫描匹配的分区，不匹配的直接跳过。这就是分区表能大幅提升查询性能的根本原因。

4.4 分区裁剪的限制与注意事项

分区裁剪不是万能的。我遇到过几次分区裁剪失效的情况，总结下来主要有这么几种：

  • 分区键被函数包裹：比如 WHERE UPPER(city) = 'BEIJING'，优化器无法直接推断分区范围。
  • 使用 OR 条件：如果 OR 条件中有一个分支不涉及分区键，裁剪可能失效。
  • 子查询或 JOIN：某些复杂的子查询或 JOIN 条件，优化器无法准确判断分区范围。
  • 分区键类型不匹配：比如分区键是 date 类型，但查询条件传了字符串，隐式转换可能导致裁剪失效。

避坑指南：我曾经在生产环境遇到一个慢查询，排查了半天才发现是分区键上用了 DATE() 函数。去掉函数后，查询从 3 秒降到了 50 毫秒。所以，写查询时一定要检查分区键上有没有多余的操作。

4.5 如何验证分区裁剪是否生效

验证分区裁剪很简单，用 EXPLAIN 看执行计划就行。我习惯这样操作：

EXPLAIN (ANALYZE, BUFFERS) 
SELECT * FROM orders WHERE order_date = '2024-05-15';

如果执行计划中只出现了一个分区的名字（比如 Seq Scan on orders_2024_q2），说明裁剪生效了。如果出现了所有分区的名字，那就说明裁剪没起作用，得回去检查查询条件。

小技巧：我建议在开发环境就养成看执行计划的习惯。每次写完分区表查询，顺手跑一下 EXPLAIN，确认裁剪生效了再上线。这花不了几秒钟，但能避免很多线上问题。

4.6 小结

声明式分区是 PostgreSQL 10 之后的首选方案，语法简洁、内核自动管理。继承式分区虽然老，但在兼容旧版本时还有用武之地。分区裁剪是分区表性能的核心，用好它能让查询快一个数量级。记住：分区键上别加函数，WHERE 条件尽量精确，执行计划常看看。

← 上一章 📖 返回目录 下一章 →