选qdrant写入更快（单节点upsert快1.5–2倍），但需nvme磁盘；milvus对cpu/内存要求高，高并发易阻塞；weaviate居中，batch_size需≥100才提速。
选 Milvus 还是 Qdrant？看写入吞吐和硬件限制
Milvus 对 CPU 和内存更“贪”，尤其在高并发写入时容易卡在 insert 阻塞，背后是它默认启用同步刷盘 + 多层缓存协调；Qdrant 用 RocksDB 做底层，写入路径更直，upsert 在单节点上压测常比 Milvus 快 1.5–2 倍，但要求磁盘随机读写强（NVMe 推荐）。Weaviate 则夹在中间——它用倒排+向量混合索引，写入快于 Milvus 但慢于 Qdrant，且对 batch_size 敏感：设成 100 以上才明显提速，设太小会触发大量 HTTP 小包。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 日均新增向量 qdrant，开
sync=true保一致性，别碰consistency_level - 需要实时更新+删除大量旧向量（比如推荐系统冷热切换）→ Milvus 的
delete接口语义最清晰，Weaviate 的delete_objects实际是逻辑标记，得靠定期compaction - 用 Kubernetes 编排 → Qdrant 的单进程模型更易水平扩缩，Milvus v2.4+ 虽支持
standalone模式，但dataNode和queryNode分离后，search延迟抖动变大
Weaviate 的 vectorIndexConfig 怎么调才不翻车
很多人一上来就改 maxConnections 或 efConstruction，结果搜索精度掉点、内存暴涨。根本原因是 Weaviate 默认用 HNSW，而 HNSW 的性能拐点不在参数本身，而在数据分布是否满足“局部密度均匀”——比如商品 Embedding 经常集中在某几个语义簇，强行调高 ef 只会让 top-k 返回更不准。
实操建议：
立即学习“Python免费学习笔记（深入）”；
-
vectorIndexType: "hnsw"下，先跑GET /v1/objects/{className}/aggregate看向量维度分布，如果stddev> 0.3 ×mean，说明嵌入质量差，调参前先换模型 -
ef别超2 × k（k 是你 search 时的limit），否则召回率不升反降；maxConnections设成min(64, 2 × CPU核心数)更稳 - 想关掉向量索引做纯属性过滤？不能只删
vectorIndexConfig，得显式设vectorIndexType: "none"，否则 Weaviate 仍会默默建空 HNSW
Milvus 的 search 耗时突然飙升，先查这三处
不是所有慢搜都怪索引或硬件。Milvus v2.3+ 的 search 请求实际走两跳：先由 proxy 解析 expr，再发给 queryNode 执行。中间任一环节卡住，time_cost 就会虚高。
常见错误现象：
- 日志里反复出现
"timeout to get query result from QueryNode"→ 八成是queryNode的cache.memory_limit不够，导致频繁驱逐索引页 - 加了
output_fields后延迟翻倍 → Milvus 默认把非主键字段存在delta_log，查时要合并 base + delta，建议把高频返回字段全设为primary_key或提前load_collection -
search返回空但没报错 → 检查anns_field是否拼错，Milvus 不校验字段是否存在，错写成"vector_filed"会静默退化为全表扫描
Qdrant 的 scroll 和 search 什么时候该选谁
scroll 不是分页替代品，它是为“导出全量”设计的流式接口；search 才是真·检索。但很多人用 scroll 做分页，结果发现 offset 越大越慢——因为 Qdrant 底层按 ID 排序，scroll 每次都从头扫，O(n) 时间复杂度。
使用场景区分：
- 要拉取全部向量做离线聚类 → 用
scroll，配合limit=10000和with_vectors=true - 用户搜“蓝牙耳机”，想分页看结果 → 必须用
search，offset改成游标式scroll_id（Qdrant v1.7+ 支持），否则第 100 页耗时可能超 3s - 需要按时间范围 + 向量相似度混合排序 → Weaviate 的
nearVector+where更自然，Qdrant 得先search出 ID，再用get查元数据二次过滤
向量数据库没有银弹，Milvus 强在生态和运维工具链，Qdrant 胜在轻量和写入确定性，Weaviate 黏性来自 schema + 向量一体化。但所有这些优势，都会在你第一次忽略 consistency_level、search_params 或 auto_compaction 的默认值时消失。
