问题出现得很突然，日志倒是留得挺全。持续小批量写入一周后，同样的查询从几十毫秒涨到一秒以上，数据量其实只增加了不到两成。
刚开始盯着「索引在大 segment 上才生效」，折腾了半个多小时，排掉了。
真正麻烦的地方在于，几个原因的现象几乎一样。小批量写入产生大量小 segment，扫描开销变大。也可能是删除标记没有真正清理，查询仍要过滤。
还有一种情况，查询并发上来后资源竞争明显。
上来先看集合的 segment 数量
python -c "print(client.get_collection_stats('docs'))"手动触发合并压缩
client.compact('docs')随后确认合并任务完成
python -c "print(client.get_compaction_state('docs'))"调整写入批大小，减少碎片产生
python ingest.py --batch 2000怎么算真的好了，看的是同一批现象。segment 数量明显下降，查询耗时回落到百毫秒以内，索引也能正常生效。
补一句。合并会占用大量 IO 和磁盘空间，线上执行要挑低峰期，磁盘余量不足时可能直接把服务拖垮。如果同一现象隔几天又出现，说明根因没找到，别当偶发处理。