PostgreSQL索引膨胀与无用索引治理：从监控到清理的完整实战-代码聚汇网

PostgreSQL索引膨胀与无用索引治理：从监控到清理的完整实战

随缘惜情·2026-08-29·阅读 23 GEO检测（免费）

PostgreSQL索引膨胀无用索引

|难度：普通|阅读约 18 分钟

1. 为什么说“无用的索引”是磁盘杀手

接手PostgreSQL运维的人，大概率会遇到这样一个场景：数据库跑了几个月，数据量涨得不多，但磁盘占用翻了好几倍。查了半天，发现罪魁祸首往往不是数据表本身，而是一堆默默吃磁盘的索引。

先说结论：索引膨胀和高成本索引带来的磁盘浪费，在水电缴费单里属于“隐藏扣费项”，平时看不着，月底一看吓一跳。

拿我自己的例子来说，之前维护过一套订单系统，核心订单表大概2000万行，数据本身占4GB左右。你猜索引占了多少？12GB。表的索引体积是数据体积的三倍。更离谱的是，其中有三个联合索引从来没被查询计划用过——它们是在业务初期“为了以防万一”建上去的，后来业务逻辑改了，查询条件变了，这三个索引就成了一把永远不会被打开的锁，扔在磁盘上，每天占用大量空间，还会拖慢写操作的速度。

这就是“无用索引”的概念：它不是数据库系统自动创建的约束索引，而是人工创建后，因为查询模式变化、索引设计不合理等原因，长期没有被查询计划选择使用的索引。它们不会报错，不会预警，就是安静地躺在那里，把磁盘空间越吃越多。

PostgreSQL的索引膨胀问题还有另一层特殊性。默认的B-tree索引在MVCC机制下，更新一行记录时，旧的索引条目并不会被立即删除，而是标记为“死元组”等待后续清理（VACUUM）。如果清理不及时、清理策略不合理，这些死元组就会像垃圾一样堆积在索引页面里，导致索引体积远大于实际键值数量。

简单类比一下：索引好比一本书的目录。正常情况下，目录只有几页纸。但如果你每次修改正文内容后，都把旧的目录条目留着不擦掉，改一次加一条，目录就会越来越厚。最终目录比正文还厚，查书翻目录反而更慢。这就是索引膨胀。

所以“定期清理无用索引”这个需求，拆开来看其实是两个动作：第一，找出那些确实没用、可以安全删除的索引；第二，对仍然需要保留但已经膨胀的索引做重建瘦身。两个动作配合，才能真正把磁盘空间释放出来。这篇文章就以这两条线展开，完整讲讲从监控到落地的处理方案。适合PostgreSQL DBA、后端开发、以及所有用PG做核心技术栈的团队参考。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 索引膨胀的本质：搞清楚它为什么会胀

2.1 MVCC机制让索引“只增不减”

PostgreSQL的多版本并发控制（MVCC）机制，是索引膨胀的根本原因。简单说，PG对一行数据的更新，不会直接覆盖旧值，而是插入一个新版本的行，旧版本行留存在数据页里，直到VACUUM来清理。

索引条目也是同样的逻辑。当你UPDATE一行时，如果更新的列恰好是某个索引的键列，PG会在索引里插入一条指向新版本行的索引项；而指向旧版本行的索引项，会一直保留到VACUUM处理它为止。

这就导致一个结果：高频UPDATE的列，其索引的写入量远大于实际数据变化量。如果你比较关注写入放大，可以换个角度理解——索引本身也有写入放大效应，一个UPDATE操作，可能带来数据表1次写入加索引N次写入。N等于这行数据涉及的索引数量。

所以很多团队有“索引越多越好”的错误认知，实际上在高写入场景下，多一个索引就多一份写入放大。索引不是越多越好，而是越精准越好。

2.2 膨胀率怎么量化：bloat估算

既然要清理，就得先知道膨胀有多严重。PostgreSQL里有一个传统办法：通过收集统计信息来对比“实际页面数”（relpages）和“按数据量推算的理论页面数”。

理论页面数的推算公式大致是：

code复制理论页面数 ≈ 元组数 / (页面大小 / (元组平均大小 + 索引条目额外开销))

这个公式算起来麻烦，而且数据不准。更实用的方案是用第三方工具，比如pg_bloat_check、pg_repack附带的检测脚本，或者用社区广泛流传的bloat_estimation.sql脚本。

这里贴一段我在生产环境用过的索引膨胀检测SQL，基于pg_statistic数据估算，能够比较准地评估B-tree索引的膨胀率：

sql复制SELECT
    current_database(),
    schemaname,
    tablename,
    indexname,
    ROUND((
        CASE WHEN reltuples = 0 THEN 0
        ELSE relpages::numeric / (1 + (reltuples / (CASE WHEN page_size = 0 THEN 1 ELSE page_size END)))
        END
    )::numeric, 2) AS bloat_ratio,
    relpages AS actual_pages,
    ROUND((
        relpages * 8 / 1024
    )::numeric, 2) AS actual_size_mb
FROM (
    SELECT
        ns.nspname AS schemaname,
        t.relname AS tablename,
        i.relname AS indexname,
        t.reltuples,
        i.relpages,
        current_setting('block_size')::numeric AS page_size
    FROM pg_class t
    JOIN pg_namespace ns ON ns.oid = t.relnamespace
    JOIN pg_index ix ON t.oid = ix.indrelid
    JOIN pg_class i ON i.oid = ix.indexrelid
    WHERE t.relkind = 'r'
      AND i.relpages > 0
) s
WHERE bloat_ratio > 2
ORDER BY bloat_ratio DESC;

这段SQL的核心逻辑是：用pg_class.relpages拿到索引实际占用的页面数，用pg_class.reltuples拿到估算行数，两者做比得到膨胀倍数。膨胀倍数大于2，说明索引体积至少是理论最小体积的两倍，值得关注。

注意，这个脚本是估算，不是精确计算。比如reltuples可能是ANALYZE更新后的近似值，有一定误差。但它足够用于发现明显的膨胀问题，能够在日常巡检中快速筛选出“嫌疑索引”。

2.3 膨胀索引的影响：不只是磁盘空间

很多人以为索引膨胀只影响磁盘占用，实际上影响远不止这些：

查询效率下降：索引膨胀后，扫描一个逻辑上只有100个键值的索引，可能要读上千个索引页面。索引的实际高度变高，从根节点到叶子节点的路径变长，单次索引检索的IO次数增加。极端情况下，优化器会放弃使用该索引，转向顺序扫描，导致SQL性能雪崩。
内存缓冲池失效：膨胀的索引占用了shared_buffers里宝贵的缓存空间。其他热数据被挤出缓存，导致整体命中率下降，更多的磁盘IO涌现。
写放大加剧：每次INSERT/UPDATE/ DELETE操作，需要维护索引结构。索引页面越多，维护成本越高。同一个索引，膨胀后和维护良好的状态相比，写入成本可能差一个数量级。
备份恢复时间变长：磁盘上的一份数据，备份时全部要转储。索引占的空间越大，备份文件越大，恢复时间越长。对这种“隐性成本”，运维团队体会最深。

3. 监控实操：用SQL脚本定位无用索引和膨胀索引

3.1 三步定位无用索引：扫描次数、命中率、重复度

识别“无用索引”，核心依据是pg_stat_user_indexes视图。这个视图记录了每个索引的使用统计信息，包括顺序扫描次数（idx_scan）、元组读取数（idx_tup_read）等。

第一步：找出从未被扫描过的索引

sql复制SELECT
    schemaname,
    relname AS table_name,
    indexrelname AS index_name,
    idx_scan,
    pg_size_pretty(pg_relation_size(indexrelid)) AS index_size
FROM pg_stat_user_indexes
WHERE idx_scan = 0
  AND indexrelid NOT IN (
      SELECT conindid FROM pg_constraint WHERE contype IN ('p', 'u')
  )
ORDER BY pg_relation_size(indexrelid) DESC;

注意最后那个子查询：排除主键约束和唯一约束对应的索引。这类索引的作用不仅是加速查询，更重要的是保证数据唯一性，不能因为“扫描次数少”就删除。

第二步：查看索引命中率

一个索引即使有扫描次数，命中率很低（比如扫描很多次但读取的元组很少），也值得怀疑。比如idx_scan很大，但idx_tup_read很小，说明查询经常用这个索引去定位，却很少能找到符合条件的数据——可能索引选择度太差，优化器却一直在误用。

sql复制SELECT
    schemaname,
    relname AS table_name,
    indexrelname AS index_name,
    idx_scan,
    idx_tup_read,
    idx_tup_fetch,
    ROUND(100 * idx_tup_read / NULLIF(idx_scan, 0), 2) AS avg_tuples_per_scan
FROM pg_stat_user_indexes
WHERE idx_scan > 0
ORDER BY avg_tuples_per_scan ASC;

如果avg_tuples_per_scan长期小于1，说明大多数情况下这个索引扫描一次只能找到不到一行数据——那还不如直接走顺序扫描，索引的效率存疑。

第三步：查重索引

两个索引如果键列完全相同，或者一个索引的键列是另一个的前缀，就会产生大量重复维护成本。用pg_index系统表可以查到。

sql复制SELECT
    i1.relname AS index1,
    i2.relname AS index2,
    pg_get_indexdef(i1.oid) AS index1_def,
    pg_get_indexdef(i2.oid) AS index2_def
FROM pg_index i1
JOIN pg_index i2 ON i1.indrelid = i2.indrelid
    AND i1.indexrelid < i2.indexrelid
WHERE i1.indkey = i2.indkey
ORDER BY i1.relname;

这里的indkey是索引键列的数组表示，相等说明列完全一致。前缀重复的情况更隐蔽，可以通过比较indkey数组的前几位来判断。清理重复索引时要非常谨慎，配合应用方的查询语句来确认，不能想当然。

3.2 日常巡检：把监控脚本固化到定时任务

一次性的SQL查询只能解决当下问题，持续监控才能防止膨胀复发。建议把上面的检测逻辑封装成一个SQL函数或Python脚本，用cron定时每天执行，结果推送到监控平台或钉钉/企业微信机器人。

我自己维护的巡检脚本流程是这样的：

每天凌晨2点执行VACUUM ANALYZE，更新统计信息。
凌晨3点采集pg_stat_user_indexes、pg_class快照，计算当天的索引扫描次数和膨胀情况。
把异常项（扫描次数为0的索引、膨胀率超过2的索引）写入一张监控日志表。
早晨9点输出日报，DBA和开发各自认领自己负责的业务索引。

这个流程跑了半年之后，我们的索引总量下降了30%，磁盘占用减少了约18%，主库的写吞吐提升了近10%。虽然有业务增长的因素，但清理无用索引带来的效果非常显著。

4. 清理实操：安全删索引与重建瘦身全流程

4.1 删索引前的风险评估清单

删除索引是个危险操作，一旦删错了，线上SQL可能瞬间全表扫描，把数据库CPU打满。我每次删索引之前都会过一遍清单：

排查应用层是否还有代码引用这个索引：在代码仓库中全局搜索索引名，确认没有硬编码的SET enable_indexscan = off或索引提示（虽然PG不像MySQL那样支持FORCE INDEX，但ORM可能生成相关SQL）。
确认唯一约束：再次核对该索引是否用于唯一性约束，不能删。
确认复制关系：如果该表在主从复制中，删除索引后主库会生成DDL并同步到备库，要确认备库能正常执行。
选择低峰期：删除索引会短暂持有表的ACCESS EXCLUSIVE锁，在业务高峰期执行会导致整个表不可读写。务必选择业务低峰窗口。

4.2 用DROP INDEX释放空间，但要注意锁和依赖

不需要的索引直接DROP INDEX，这个操作本身很快，但它的锁级别是ACCESS EXCLUSIVE，会阻塞表的读写操作。对大表来说，即使删索引很快，锁的获取和释放也有一瞬的阻塞风险。

sql复制-- 删除单个无用索引
DROP INDEX IF EXISTS idx_user_created_at;

-- 批量删除之前，先查一遍依赖
SELECT * FROM pg_depend
WHERE refobjid = 'idx_user_created_at'::regclass;

pg_depend可以查到该索引是否被其他对象依赖。如果没有任何依赖，删除就是安全的。

4.3 REINDEX重建膨胀索引：几种方法的取舍

对于仍然需要保留、但体积已经膨胀的索引，有两个主要的重建方案：

方案一：REINDEX

sql复制-- PG12及以上版本默认可以CONCURRENTLY重建
REINDEX INDEX CONCURRENTLY idx_order_user_id;

CONCURRENTLY模式不会阻塞读写操作，但有两个限制：

不支持在事务块内执行
需要更多的临时磁盘空间，因为要创建新索引后再切换

如果索引超大（几百GB以上），还需要评估临时空间是否够用。

方案二：pg_repair在线重建（pg_repack）

pg_repack工具更强大，允许在线上重建整个表或者单个索引，不停业务。它通过创建日志表记录重建期间的数据变化，重建完成后回放日志，实现对业务几乎无感知。

bash复制# 重建单个索引
pg_repack -k --index idx_order_user_id -d database_name

# 重建整个表
pg_repack -t order_info -d database_name

注意，pg_repack需要安装扩展，并且需要使用超级用户或者有相应权限的角色来执行。另外，pg_repack对正在执行长事务的会话非常敏感——如果有老事务一直未提交，它可能会因为拿不到快照而卡住或者报错。

方案三：重建到新表再切换

对于膨胀极其严重的大索引，我有时候会直接新建一张结构相同但索引更精简的表，把数据导过去，然后切换表名。这招适合做“索引架构整改”，不只针对单索引，而是把整张表的索引设计重新做一遍。缺点是需要停写或双写，适合配合发布窗口做。

4.4 重建时机的选择：结合VACUUM策略

很多DBA以为膨胀索引只能靠REINDEX解决，其实合理的VACUUM策略可以减缓膨胀速度。VACUUM会清理掉索引里的死元组，但PG默认的VACUUM对索引的清理效率不高，因为索引页面不像堆页面那样能快速合并。

为了优化这点，PostgreSQL从11版本引入了INDEX_CLEANUP参数。可以在VACUUM时强制处理器跳过某些索引。实际上更建议配置自动VACUUM的频率和阈值，让死元组有机会被定期清理掉：

sql复制ALTER TABLE order_info SET (autovacuum_vacuum_scale_factor = 0.05);
ALTER TABLE order_info SET (autovacuum_analyze_scale_factor = 0.02);

对于特别大且频繁更新的表，默认的autovacuum_vacuum_scale_factor=0.2（也就是表中有20%的元组是死元组才触发VACUUM）太迟钝了。调低到0.05，让VACUUM更频繁地跑，有效控制死元组的存量，变相降低膨胀速度。

但这只是缓解，不是根治。长期运行后，索引物理结构仍然会变得不够紧凑，REINDEX依旧不可避免。

5. 常见问题与排查技巧实录

5.1 为什么REINDEX CONCURRENTLY会失败？

REINDEX INDEX CONCURRENTLY虽然好，但它不是银弹。我实践中遇到最多的失败原因有三种：

事务冲突：有长时间未提交的事务持有snapshot，导致新索引创建后无法获取一致的旧数据快照。排查方法是查pg_stat_activity，看有没有state = 'idle in transaction'的会话。
临时文件空间不足：CONCURRENTLY模式需要存储两份索引数据（旧索引+新索引），如果临时表空间所在的磁盘空间不够，会直接报错中止。
索引损坏：如果原索引本身有损坏（比如硬件故障导致的page corruption），REINDEX CONCURRENTLY可能创建新索引失败，但又不会自动回滚旧索引，造成“无索引可查”的状态。

解决办法：遇到失败，先查pg_stat_progress_create_index视图确认卡在哪个阶段，再根据错误日志判断是清理死锁还是空间不够。必要时直接放弃CONCURRENTLY，在维护窗口用普通REINDEX执行。

5.2 DROP INDEX之后，磁盘空间为什么没有立即释放？

这是Linux文件系统的常见现象。PostgreSQL在DROP INDEX后，文件句柄释放了，但文件系统层面可能有延迟回收，尤其在XFS或ext4文件系统上。另外，如果数据库开启了Huge Pages，也可能导致内存层面看起来占用未释放。

真正的“确认释放”方法：

bash复制# 查看表空间对应的文件大小变化
SELECT pg_size_pretty(pg_relation_size('index_name'));

# 文件系统层面
df -h

如果查询系统表确认索引已经不存在了，但磁盘占用没有降下来，很可能是WAL日志仍然保留着相关数据。等几个检查点过去，空间会被回收。不用太焦虑。

5.3 索引膨胀监控频率设多少合适？

这个没有标准答案，取决于表的大小和写入负载。一般建议：

小表（<10GB）：每周巡检一次足够
大表（>100GB）且高频写入：每天检查
超级大表（>1TB）且有定期维护窗口：每次维护窗口内检查

表格汇总：

表大小	建议巡检频率	重点关注指标
<10GB	每周一次	idx_scan=0、膨胀率>3
10GB ~ 100GB	每天或隔天一次	膨胀率>2、avg_tuples_per_scan<1
>100GB	每天一次	膨胀率>1.5、死元组占比

5.4 清理无用索引后，查询性能反而变差了？

这种情况虽然不常见，但确实会遇到。原因一般是：

你删掉的索引，偶尔会被某些低频率但重量级的查询用到。比如月底跑报表的SQL，平时不走那个索引，你以为它没用，其实报表SQL严重依赖它。
优化器统计信息不真实。删除索引后，ANALYZE统计信息没来得及更新，优化器在做计划时可能做出错误判断。

解决办法：删除索引前，用pg_stat_statements查看所有历史SQL模式，确认没有遗漏的查询模式。删除后，密切观察1~2个业务周期，如果出现慢SQL，及时重建。这里也说明一个经验：所谓“无用索引”，不能只看扫描次数，还要结合查询模式和业务周期综合判断。

6. 经验总结：从“临时清理”到“常规运维”

做索引清理这件事，一次性的DROP INDEX和REINDEX只能解决当下问题。如果团队里没有持续的监控和治理机制，过不了几个月，新的无用索引又会冒出来。我的个人体会是，把索引管理纳入常规运维流程，比每次等出问题了再救火重要得多。

几个实践下来值得推广的做法：

第一，把索引设计评审加入上线流程。 任何新索引的创建，都需要提交索引设计说明：基于什么查询创建的？预期收益是什么？是否有重复索引？上线前由DBA审核，杜绝随手建索引的习惯。

第二，定期使用pg_stat_statements分析查询模式。 很多无用索引的产生，是因为查询模式变化了，但DBA不知道。通过pg_stat_statements的top SQL分析，能够及时了解哪些查询变少了，哪些查询换了条件列，提前预判哪些索引即将变成无用索引。

第三，利用分区表减少超大数据表的索引膨胀。 数据量上到亿级后，单一大表的索引膨胀速度非常快。把表分区后，每个分区的索引体积小，REINDEX单个分区成本低得多。这也是很多大厂在PG上普遍采用的做法。

最后，重要的事情说三遍：删索引前确认三遍，删索引前确认三遍，删索引前确认三遍。 一个无用索引的代价是每天白白吃几十GB磁盘、拖慢写入；一个有用索引被误删的代价是线上查询全部变慢，彻夜紧急修复。两者孰轻孰重，相信大家都有自己的判断。实在拿不准的索引，宁可多保留一个版本周期，也不要贸然动手。