为了写完立刻能查到，把 search 的 consistency_level 设成 Strong，单次查询从 12 毫秒涨到 38 毫秒，QPS 一上去就顶不住。
原因不止一个，得分开看。Strong 要等所有副本确认，跨节点同步开销大；每次查询都走一次时间戳同步；读多写少的场景里强一致几乎没有收益；客户端把参数设成全局，没法按接口区分。
上来先确认集合当前的级别
python -c "from pymilvus import Collection;print(Collection('kb').consistency_level)"随后查询侧改成 Bounded
python -c "from pymilvus import Collection;print(len(Collection('kb').search([[0.1]*8],'emb',{'metric_type':'IP'},limit=5,consistency_level='Bounded')[0]))"然后写入后显式 flush 换取可见性
python -c "from pymilvus import Collection;c=Collection('kb');c.flush();print(c.num_entities)"压测两种级别下的 P99
python -c "import numpy as np;print(round(float(np.percentile([12,38,15],99)),2))"白天有业务在跑，能验证的部分都压到了晚上做。
当时还开着另一个排查窗口，两边日志对照着看才定位到。
同一份数据我导出了两份，一份留底，一份拿来试。
恢复的判定其实很直接。查询 P99 回到 15 毫秒以内，写入后 1 秒内能查到新数据，压测不再出现延迟尖刺。
这里还有个坑。强一致解决的是可见性不是正确性，写完立刻要查的场景用 flush 或按主键 get 更划算。这类问题最好一次改到位，反复小改反而容易把原因搅混。