33 · 增量更新、删除与索引维护

33 · 增量更新、删除与索引维护一句话向量数据长期增删改会让索引膨胀、性能下降要靠 VACUUM、REINDEX 等定期维护保持健康。本章标 是系统长期跑下去绕不开的运维现实。1. 增量写入HNSW 天然支持HNSW 索引支持边插入边维护新数据会自动加入图-- 有 HNSW 索引的表直接插入即可索引自动更新INSERTINTOitems(content,embedding)VALUES(新文档,[...]);注意每次插入都要维护索引图写入比无索引慢。大批量新增仍建议参考第 32 章临时去索引 → 导入 → 重建。2. 更新向量更新 删除旧行 插入新行PG 的 MVCC 机制UPDATEitemsSETembedding[新向量]WHEREid100;旧版本行变成死元组dead tuple不会立刻消失。索引里也会留下旧条目。频繁更新 → 死元组堆积 →表和索引膨胀。3. 删除数据DELETEFROMitemsWHEREid100;同样只是标记删除物理空间不会马上释放需要 VACUUM 回收。4. VACUUM回收死元组VACUUM清理死元组、回收空间是最重要的日常维护。-- 常规清理不锁表可日常跑VACUUM items;-- 顺带更新统计信息VACUUMANALYZEitems;PG 有autovacuum自动跑但高频增删的向量表可能需要调更激进或手动补充。让 autovacuum 更积极高频变更表ALTERTABLEitemsSET(autovacuum_vacuum_scale_factor0.05,-- 死元组达 5% 就触发autovacuum_vacuum_cost_delay0);5. 索引膨胀与重建即便 VACUUMHNSW 索引经过大量增删后图结构会退化 / 膨胀召回和速度下降。判断膨胀观察索引大小是否远超数据量、召回是否下降用第 30 章评测集。重建索引恢复健康-- 不阻塞线上读写地重建REINDEXINDEXCONCURRENTLY items_embedding_idx;CONCURRENTLY让重建期间表仍可读写生产必用。6. IVFFlat 特别注意IVFFlat 的桶是建索引那一刻用当时数据聚类定的。数据分布随时间大幅变化后桶不再能代表新数据分布。召回明显下降。所以IVFFlat 需要定期重建才能保持效果REINDEXINDEXCONCURRENTLY items_ivfflat_idx;这也是为什么持续变化的数据更推荐 HNSW增量维护能力强。7. 软删除 vs 硬删除生产常用软删除标记而非物理删-- 加删除标记ALTERTABLEitemsADDCOLUMNis_deletedbooleanDEFAULTfalse;-- 删除其实是更新标记UPDATEitemsSETis_deletedtrueWHEREid100;-- 检索时过滤掉SELECTidFROMitemsWHEREis_deletedfalseORDERBYembedding[...]LIMIT10;注意软删除的行仍在索引里会被 HNSW 检索到再过滤可能触发第 21 章的召回塌陷。删除量大时定期真正DELETEVACUUM更健康。8. 定期维护清单建议每天 autovacuum 保持开启高频表调激进 每周 VACUUM ANALYZE 重点表检查索引大小 按需 召回率下降 → REINDEX CONCURRENTLY IVFFlat数据分布大变 → 定期 REINDEX 软删除 定期物理清理已标记删除的数据9. 监控指标-- 查死元组数量判断是否需要 VACUUMSELECTrelname,n_live_tup,n_dead_tupFROMpg_stat_user_tablesWHERErelnameitems;-- 查索引大小SELECTpg_size_pretty(pg_relation_size(items_embedding_idx));n_dead_tup相对n_live_tup很高就该 VACUUM 了。10. 一句话总结增删改会产生死元组和索引膨胀靠 autovacuum 定期VACUUM ANALYZE回收召回下降时REINDEX CONCURRENTLY重建IVFFlat 尤其要定期重建。➡️ 下一章34-pgvectorscale与生态选型.md上亿规模的扩展方案与选型。