PostgreSQL索引膨胀率远超表膨胀率 主键索引持续膨胀排查

你遇到的是PostgreSQL B树索引在单调递增写入+老数据更新/删除场景下的典型膨胀问题，和autovacuum配置、运行状态无关，核心逻辑如下：

• 首先纠正一个常见认知偏差：标准VACUUM（含autovacuum触发的常规VACUUM）仅能标记死元组占用的空间为可复用，不会主动将半满的索引页合并，也不会把仍有存活条目的索引页空间归还给系统，且B树索引的页复用有严格的范围限制。
• 自增主键属于严格单调递增的索引，所有新插入的索引条目永远只会写入B树结构最右侧的叶子页。如果你的业务存在删除历史数据、更新存量老数据的操作，死元组会集中出现在主键值更小的B树左侧叶子页中——这些页里清理出来的空闲空间，永远不会被后续新插入的自增主键条目访问到，完全无法被复用。
• 从你给出的监控数据可以直接验证：表膨胀率稳定在9.97%，刚好卡在你配置的10% autovacuum触发阈值，说明autovacuum运行完全正常。表的空间复用没有顺序限制，任意数据页清理出的空间都可以被新写入复用，因此膨胀率一直维持在阈值附近；但索引因为上述的顺序写入限制，左侧页的空闲空间无法复用，随着老数据的删除/更新持续累积，就出现了索引膨胀率57%、远高于表膨胀率的现象。
• 这个现象在PostgreSQL 10、12版本普遍存在，因为直到PostgreSQL 14版本才新增了B树索引尾部空页回收的优化，对于分散在左侧的半满索引页，仍然没有自动合并回收的机制。

临时修复 #

在业务低峰期执行在线索引重建，直接清理现有膨胀：

REINDEX INDEX CONCURRENTLY public.data_entity_pkey;

该操作不会持有表的排他锁，不会阻塞正常业务读写，重建完成后索引膨胀率会降到10%以内，占用的多余空间会归还操作系统。禁止直接使用不带CONCURRENTLY参数的REINDEX，会锁表阻塞所有写入。

长期优化 #

• 如果业务存在定期清理历史数据的需求，不要使用DELETE语句零散删除，建议将表改为主键范围分区/时间分区，清理老数据时直接DROP对应分区，完全不会产生索引和表膨胀，清理效率比DELETE高两个数量级以上。
• 针对该表单独调低autovacuum触发阈值，比如将表级的autovacuum_vacuum_scale_factor设置为0.02（即死元组占比2%就触发清理），提升清理频率，减缓半满索引页的累积速度，但该方案只能降低膨胀速度，无法完全杜绝这类场景的索引膨胀。
• 建立定期维护机制，每1-2周在业务低峰期对核心大表的主键索引执行一次CONCURRENTLY REINDEX，将索引膨胀率稳定控制在可接受范围内。
• 有条件的话可以升级到PostgreSQL 14及以上版本，该版本对单调递增B树索引的空页回收做了专项优化，同场景下的索引膨胀速度会下降40%左右，但仍需要配合定期维护。

内容的提问来源于stack exchange，提问作者Monika Yadav