向量数据库内存爆掉怎么办？聊聊 HNSW、DiskANN 和 SPANN 的实战选择逻辑
在实际部署中，我们通常需要在 HNSW、SPANN 和 DiskANN 这三种索引方案中做取舍。
首先聊聊最常用的 HNSW。它的响应速度确实惊人，但代价是内存占用极高。HNSW 将图结构全部缓存在内存中，这意味着你的内存必须能装下所有的向量数据以及额外的图索引开销。如果你追求极致的低延迟，且数据量在 1000 万条以下，HNSW 依然是首选。但它的风险在于，一旦内存占用率突破临界点，整个服务会直接崩溃。
当你面对亿级数据且预算有限时，必须考虑 DiskANN。这是真正的“省钱方案”，它将大部分数据存储在磁盘上，内存中仅保留一个极小规模的缓存索引。虽然在查询延迟上，DiskANN 肯定比 HNSW 慢，但在处理海量数据时，它的性价比是无敌的。对于那些对延迟不那么敏感，但数据量巨大的场景，直接上 DiskANN 能省下大笔的服务器费用。
而 SPANN 则是一个折中方案。它通过聚类压缩来降低内存压力，试图在 DiskANN 的低成本和 HNSW 的高性能之间找一个平衡点。它适合那种既不能接受 DiskANN 较高延迟，又买不起 HNSW 所需海量内存的中间地带。
在实战部署中，我建议开发者不要盲目追求所谓的“最新技术”，而要建立一套基于资源压力的排查逻辑。
首先，实时监控当前索引的内存占用比。如果你的内存占用率已经超过 80%，且数据量还在持续增长，那么此时不要尝试通过优化代码来省内存，而应该直接考虑将索引迁移到 DiskANN。
其次，在迁移之前，可以尝试调整压缩参数，比如使用 PQ（乘积量化）量化。通过牺牲一定的检索精度，可以显著降低内存占用。但这里有一个坑：量化参数设置得过激，会导致召回率断崖式下跌。建议在小规模数据集上先跑一遍对比测试，绘制出 QPS 与内存占用的曲线图，找到精度损失与内存节省的平衡点。
总结一个简单的选择路径：追求极致速度 → 数据量 $\le$ 1000万 → HNSW；预算有限 → 数据量 $\ge$ 1亿 → DiskANN；处于中间地带 → SPANN。选型时最核心的考量指标不是理论性能，而是你的钱包规模和业务对延迟的容忍度。
