How do you troubleshoot slow search performance in Milvus?

Slow search in Milvus usually traces back to one of a handful of well-known causes, each with a fairly direct diagnostic path.

1. Check whether an appropriate index actually exists - a collection searched without an index (or accidentally falling back to FLAT) performs full brute-force comparison, which is dramatically slower at scale than any approximate index.
2. Check index search parameters - parameters like HNSW's ef or IVF's nprobe directly trade search speed for recall; an unnecessarily high value for the required accuracy wastes time on marginal recall gains.
3. Check whether the collection (and specifically the queried partitions) are fully loaded - searching against data that's only partially loaded, or triggering a reload mid-query, adds latency beyond normal search time.
4. Check Query Node resource pressure - CPU, memory, or disk I/O saturation on Query Nodes (especially relevant for memory-mapped or disk-based indexes like DiskANN) directly slows every query hitting that node.
5. Check for unnecessarily broad scalar filters or missing partition scoping - a query that could be scoped to a specific partition but instead scans the whole collection does more work than necessary.
6. Check replica count relative to query concurrency - a high volume of concurrent queries against a single replica can queue up, even if any individual query would otherwise be fast.

A useful diagnostic habit is isolating whether slowness is per-query (pointing at index type/parameters or data scope) or throughput-related (many queries queuing under load, pointing at replica count or Query Node capacity), since the two symptoms have largely different fixes.