内存撑不住的时候，向量检索怎么选索引？

向量数据库最让人头疼的就是内存开销，尤其是数据集规模一旦上来，全量加载到内存里的成本简直是天文数字。我在做项目时发现，单纯堆内存根本不是长久之计，必须在 HNSW、SPANN 和 DiskANN 之间做取舍。

简单粗暴的结论是：如果你追求极致的响应速度且数据量在千万级以下，HNSW 依然是首选；但如果数据量到了亿级，且预算有限，必须考虑磁盘索引。

几个关键的技术点踩坑心得：

• HNSW (In-Memory)： 速度快得惊人，但内存占用极高。它把图结构全部缓存在内存里，一旦 OOM（内存溢出），整个服务直接崩掉。
• DiskANN (On-Disk)： 真正的省钱方案。它把大部分数据存在磁盘上，内存只留一个小规模的缓存索引。虽然延迟比 HNSW 高，但在处理海量数据时，性价比无敌。
• SPANN： 算是两者的折中，通过聚类压缩来降低内存压力，适合那些既不能接受 DiskANN 的延迟，又买不起 HNSW 所需内存的场景。

如果你现在正面临内存溢出或服务器成本过高，建议按照这个逻辑排查：
1. 检查当前索引的内存占用比。
2. 如果内存占用率 > 80% 且数据仍在增长，直接尝试将索引迁移到 DiskANN。
3. 调整压缩参数（如 PQ 量化），在精度损失和内存节省之间找平衡点。

对于追求实战部署的开发者，建议先在小规模数据集上对比这三种索引的 QPS 和内存曲线，别盲目跟风选最先进的，得看你的钱包和延迟容忍度。