我们使用 milvus 和 CPU 部署的默认配置，每条新记录都被引入 milvus，我们正在为这个集合在 milvus 中重建索引，但是我们发现构建索引所需的时间增加了（当单个工作区中的记录达到大约150K）大约半分钟
所以我们删除了手动构建索引，让 milvus 重建基于，index_file_size但是那里有一些东西，因为在另一个工作区中搜索，在禁用手动索引之前已经正确索引变得比以前慢得多
所以我的问题是？
index_file_size？您对cpu在生产中使用 milvus 有什么建议吗？我假设您使用的是 Milvus 1.x 我不熟悉“工作区”这个表达方式，我假设您指的是集合或分区
对于你的第一个问题：
can index in a workspace be affected by non indexed workpsace ?
我假设您在问：集合的正在进行的索引任务是否会受到未编入索引的集合的影响。
A：当然可以，Milvus 1.x 是一个独立的解决方案，不同的任务共享相同的资源。尽管第二个集合没有被索引，但搜索任务仍然会占用大量资源，因为它是一个非常占用 CPU 的任务。
why inserting and building the index take this very long time ?
插入应该不会占用很长时间，请检查时间是否花在网络IO上。构建索引是一项非常耗费 CPU 的任务，它可能会占用相对较长的时间，具体取决于数据的大小、索引的类型以及您用于托管 Milvus 的机器。如果时间太长，可以考虑使用 GPU 或者切换到其他索引。
how to choose the perfect index_file_size ? do you have any suggestions in general working with cpu milvus in production ?
如果没有连续添加数据，较大的 index_file_size 对搜索性能有很大的好处。但是，如果有新添加的数据，您可能希望有一个较小的 index_file_size，因为正在插入的段没有被索引，这可能会损害整体搜索性能。
对于 index_file_size 对索引构建性能的影响，我们假设向量数量为 ，构建 ivf 索引N的复杂度为O(θ * N)，θ 为常数。总成本不应受 index_file_size 的影响。