用途：当出现“搜索很慢”“延迟高”“查询耗时过长”“QPS 低”“吞吐不足”等反馈时，用于诊断并修复 Qdrant 搜索性能问题。常见原因包括：工作集超出可用内存、请求过于复杂（如 hnsw_ef 过高、无负载索引的复杂过滤）、批量上传后优化器仍在后台运行、以及集群网络或硬件问题。
单次查询过慢（延迟）：先验证同一请求第二次是否明显更快（提示内存压力）；再用 with_payload: false 与 with_vectors: false 判断负载读取是否为瓶颈；如有过滤，逐个移除条件定位问题过滤。常见修复：微调 HNSW 参数、启用标量量化等内存量化、用 Matryoshka 模型降低向量维度、高维向量采用过采样加重打分、Linux 磁盘密集场景启用 io_uring。
QPS 不足（吞吐）：将 default_segment_number 调为 2 以减少分段；改用批量搜索 API，replace 单条查询；启用量化降低 CPU 开销；增加副本分散读负载。
过滤检索慢：为过滤字段建立负载索引；主过滤条件使用 is_tenant=true；复杂过滤可尝试 ACORN；避免把嵌套过滤条件作为主过滤，否则可能退化为读取原始负载；若负载索引在 HNSW 构建后才添加，需触发重新索引以生成可过滤子图链接。
优化器并行更新：用 indexed_only=true 重跑查询，若明显更快说明优化器仍在索引分段；无查询时 CPU 或 IO 仍高也说明如此。可降低 optimizer_cpu_budget 为查询留出 CPU，或用 prevent_unoptimized=true，使分段达到 indexing_threshold 后新增点进入延迟状态。
不应做的事：对量化设 always_ram=false（每次搜索触发磁盘抖动）；对延迟敏感的生产环境把 HNSW 放磁盘（仅适合冷存储）；为吞吐增加分段数（应更少）；给每个字段都建负载索引（浪费内存）；未检查优化器状态就归咎 Qdrant。