PostgreSQL从10版本开始大幅改进声明式分区之后，分区表在生产环境的使用率明显上升。但不少团队在索引设计上栽了跟头：明明在分区父表上建了索引，跨分区查询却依然要做全分区扫描；或者删除一个旧分区时，因为索引依赖问题导致操作卡住。这些问题的根源在于没有搞清楚本地索引和全局索引在PostgreSQL中的实现机制与适用边界。这篇文章从索引的组织结构出发，把两类索引的行为差异掰开讲清楚。
一、PostgreSQL分区索引的底层组织方式
首先要明确一点：PostgreSQL原生支持的分区索引是本地索引（Local Index）。当你在分区父表上执行CREATE INDEX时，PostgreSQL会自动为每一个子分区创建一份结构相同的独立索引，父表上的那个索引只是一个"目录"性质的占位对象，本身不存储任何索引数据。真正存储数据的是每个分区上各自的索引副本。
这种设计带来的直接后果是：索引项与数据行在物理上是同分区绑定的。每个分区的索引只包含本分区内的行，索引的物理位置（relfilenode）也随分区独立管理。你可以通过下面这个查询观察分区索引的实际结构：
-- 在分区父表上创建索引
CREATE INDEX idx_orders_created ON orders (created_at);
-- 查看自动生成的子分区索引
SELECT c.relname AS 索引名,
p.relname AS 所属分区
FROM pg_index i
JOIN pg_class c ON c.oid = i.indexrelid
JOIN pg_class p ON p.oid = i.indrelid
WHERE p.relname LIKE 'orders%';
查询结果会显示每个分区都有一份名为orders_created_idx加上分区后缀的索引。这与Oracle等数据库中真正物理统一存储的全局索引有本质区别——PostgreSQL中并不存在一个跨越所有分区的单一B-tree结构。
那所谓的"全局索引"在PostgreSQL中怎么实现？通常有两种途径：一是不用分区表，直接在普通表上建索引（自然就是全局的）；二是借助一些变通手段，比如把分区键和业务键组合后建在表达式索引上，或者使用Citus等扩展来模拟全局约束。理解了这个前提，后面的差异讨论才有意义。
二、查询性能与分区裁剪的差异
本地索引的最大优势是配合分区裁剪（Partition Pruning）工作。当查询条件包含分区键时，规划器能直接排除不相关的分区，只需要扫描少量分区的本地索引。比如按月分区的订单表，查询某个月的订单，只会命中一个分区的索引，I/O开销极小。执行计划中你会看到只出现了一个Scan节点：
EXPLAIN SELECT * FROM orders WHERE created_at >= '2024-03-01' AND created_at < '2024-04-01' AND customer_id = 88231;
如果查询条件里没有分区键，比如只按customer_id查某个客户的所有订单，本地索引的表现就不理想了：规划器无法裁剪分区，必须对每个分区的索引分别做查找，再把结果合并。假设你有120个月度分区，即使每个分区的索引查找很快，120次索引探测加上结果合并的总开销也不可忽视，这种模式在执行计划里表现为Append节点下挂着一长串Index Scan。
这正是全局索引理论上能弥补的场景。在Oracle中，全局索引是一棵覆盖全表的B-tree，一次索引探测就能定位到目标行，无论它在哪个分区。PostgreSQL没有原生等价物，但可以评估替代方案：如果这类不带分区键的查询频率极高，且数据量可控，也许根本不该分区；如果一定要分区，可以考虑冗余一张按查询维度组织的汇总表，或者引入物化视图来承接这类查询。
三、分区维护操作的成本对比
索引选型对分区维护的影响是最容易被低估的部分。本地索引在这方面的优势非常突出：删除或分离（DETACH）一个分区时，其他分区的索引完全不受影响，不需要任何重建。这也是分区表"随用随删"生命周期管理的基石：
-- 本地索引模式下，删除分区是轻量操作 DROP TABLE orders_2023_01; -- 分离分区同样不触碰其他索引 ALTER TABLE orders DETACH PARTITION orders_2023_01;
而在Oracle等支持全局索引的数据库里，DROP PARTITION默认会使全局索引失效，需要加UPDATE GLOBAL INDEXES子句在线维护，代价是删除操作本身变慢，且产生大量undo。PostgreSQL的本地索引天然规避了这个问题，这是它架构上的一个实用优点。
反过来，如果你在PostgreSQL中用变通手段模拟全局唯一性（比如在父表上建触发器加锁表校验，或用单独的约束表来维护唯一键），那么每次数据写入和分区删除都会涉及额外的事务和锁竞争，维护成本会显著上升。团队需要在"跨分区唯一约束"和"分区快速维护"之间做取舍，这两者在PostgreSQL当前实现下很难兼得。
四、唯一约束的关键限制与应对
本地索引模式下，唯一索引必须包含分区键。这不是bug而是必然：PostgreSQL无法跨分区检查唯一性，只有把分区键纳入索引，才能保证每个唯一键值必然落在唯一确定的分区里，唯一性检查才能在各分区内独立完成。下面的语句是合法的：
-- 合法：唯一索引包含分区键 created_at
CREATE UNIQUE INDEX uk_orders_order_no
ON orders (order_no, created_at);
-- 报错：缺少分区键，无法保证全局唯一
CREATE UNIQUE INDEX uk_orders_order_no2
ON orders (order_no);
-- ERROR: unique constraint on partitioned table
-- must include all partitioning columns
这个限制的痛点在于业务主键往往不含时间字段。比如订单号order_no在业务语义上就是全局唯一的，但订单表按created_at分区后，数据库层面无法强制这个唯一性。常见的应对方案有三种：第一种是让order_no本身编码分区信息（比如前缀含日期），使业务校验等价于数据库校验；第二种是维护一张独立的小表作为唯一性登记表，写入时先插入登记表利用其唯一约束拦截重复，代价是每次写入多一次往返；第三种是使用序列或UUID生成主键，从生成机制上保证不重复，放弃数据库层的强约束。
如果业务确实无法接受这些折中，且跨分区唯一约束是硬需求，那就要重新评估分区策略本身，或者考虑支持全局索引的其他数据库产品。技术选型没有银弹，认清PostgreSQL的这个边界比强行绕过它更重要。
五、实际选型的判断框架
综合前面的分析，可以归纳出一套简单的判断流程。第一步看查询模式：绝大多数查询都带分区键（通常是时间范围查询），本地索引配合分区裁剪就是最优解，直接用原生方案；存在大量不带分区键的点查，先评估数据量是否真的需要分区，很多时候合适的索引加BRIN就能解决膨胀问题。
第二步看约束需求：主键或唯一约束能自然包含分区键，选本地索引没有任何障碍；业务主键不含分区键且强依赖数据库唯一性保障，就要提前设计好替代方案，不要等上线后才发现。第三步看分区生命周期：频繁滚动删除旧分区的场景，本地索引的免维护特性价值巨大；分区基本只增不删，索引维护成本的权重就可以降低。
最后提醒一点实践细节：在分区父表上创建索引时使用CREATE INDEX ON ONLY加逐分区CREATE INDEX ... ON partition再ATTACH PARTITION INDEX的组合，可以在大表上避免长事务锁表，配合REINDEX CONCURRENTLY还能安全地重建索引。掌握这些细节，分区表的索引管理才能真正做到既高效又稳态。
PostgreSQL分区表全局索引本地索引修改时间：2026-09-16 01:18:43