看到这个案例，我第一反应是怀疑——1G内存检索2500万向量，还要在强标量过滤下做到毫秒级响应，这听起来像是天方夜谭。但仔细看了Milvus社区的技术分享后，我发现关键在于FLAT索引结合了高效的标量过滤下推机制。传统上，FLAT（暴力搜索）被认为是内存和计算开销最大的方案，但Milvus通过优化向量与标量过滤的协同执行，大幅减少了不必要的距离计算。具体来说，它利用倒排索引或位图预过滤标量条件，只对符合要求的向量子集进行暴力搜索，从而在内存占用极低的情况下实现高吞吐。

从我个人的经验来看，很多向量数据库在处理复杂过滤时都会出现性能瓶颈，尤其是当标量过滤选择性很高时，索引结构反而成了累赘。Milvus这个方案让我意识到，有时“简单粗暴”的FLAT在特定场景下可能比HNSW或IVF更实用。不过，我也有一个疑问：如果标量过滤的选择性较低（比如过滤后还剩50%的向量），FLAT的响应时间会不会急剧退化？另外，这种方案对内存带宽的要求是否隐藏了硬件成本？

从行业趋势看，这提醒我们向量搜索的优化不能只盯着ANN算法，与标量过滤的深度结合才是落地关键。未来，或许会有更多数据库将向量索引和传统SQL引擎融合，而非简单地“加个向量插件”。