VACUUM通过清理表中死亡元组间接提升索引效率，减少无效扫描，但不释放索引空间；需配合autovacuum和REINDEX操作控制膨胀，VACUUM FULL则会重建索引以紧凑存储。
在PostgreSQL中，VACUUM操作主要用于回收被删除或更新行所占用的存储空间，并维护表的数据健康状态。它对索引的影响是间接但重要的，理解这种关系有助于优化数据库性能和维护策略。
1. VACUUM如何影响索引
VACUUM本身不会直接重建或修改索引结构，但它通过清理表中的“死亡元组”（dead tuples）间接影响索引的使用效率：
- 减少索引扫描的无效访问：当执行DELETE或UPDATE时，旧版本的行不会立即从磁盘上移除，而是标记为“死亡”。这些死亡元组对应的索引条目仍然存在。VACUUM会清除这些无用的表数据，从而避免后续查询通过索引定位到已不存在的行版本。
- 不释放索引空间：标准VACUUM（非FULL模式）不会回收索引中因删除而产生的空闲空间。也就是说，即使表中大量数据被删除，索引文件大小可能仍保持不变，除非使用其他方式处理。
- 防止索引膨胀带来的性能下降：虽然VACUUM不清除索引中的死项，但定期运行VACUUM能保证表层面的整洁，配合后续的索引维护操作（如REINDEX），可有效控制整体膨胀。
2. 索引相关的自动清理行为（autovacuum）
PostgreSQL的autovacuum机制会根据表的更新频率自动触发VACUUM操作，这对索引也有重要意义：
- 频繁更新/删除的表会产生更多死亡元组，autovacuum及时清理这些元组，可以降低查询时需要跳过无效数据的概率，提升通过索引访问的有效性。
- 如果autovacuum滞后，可能导致查询执行计划变差，比如优化器因统计信息陈旧而选择错误的索引，或者实际执行中需遍历更多无效行。
- 长时间未清理还可能引发事务ID回卷风险，进而影响整个数据库稳定性，包括索引操作。
3. 何时需要重建索引
尽管VACUUM不能压缩索引体积，但在以下情况下建议手动重建索引以恢复性能：
- 表经历了大批量删除或更新后，索引明显膨胀（可通过pg_indexes_size()和历史值对比判断）。
- 查询性能下降，且执行计划显示索引扫描效率降低。
- 运行REINDEX INDEX或REINDEX TABLE可重新构建索引，去除碎片，释放空间。
4. VACUUM FULL与索引的关系
VACUUM FULL与普通VACUUM不同，它会锁定表并重写整个表数据，同时紧凑存储：
- 在此过程中，表按新顺序写入，原有索引将失效，因此系统会强制重建所有相关索引。
- 这会导致较高的I/O开销和长时间锁表，应谨慎使用。
- 效果显著：表和索引都会变得更紧凑，查询性能通常得到提升。
基本上就这些。VACUUM不直接操作索引，但它是维持索引高效工作的基础环节。配合合理的autovacuum设置和定期索引维护，才能确保数据库长期稳定运行。
