嘿，先给你的实测点个赞——单索引（合理规模）比一堆小索引性能更好，完全符合Elasticsearch的设计逻辑！大量小索引会带来元数据管理、分片调度的额外开销，查询时还要跨多个索引合并结果，反而拖慢速度，你的测试结果刚好验证了这一点，这是我们制定方案的重要依据。

结合你的年数据规模（6.58亿条）和对搜索、排序、删除效率的要求，我整理了以下针对性方案：

一、先搞定索引分片与规模规划 #

从你的测试来看，单索引存35.6万条时性能最优，那我们就围绕这个基准来设计：

• 单索引的文档数控制在30-40万条这个区间，和你的实测最优值对齐；
• 分片设置：当前你用2分片0副本，生产环境建议至少加1个副本（保证高可用），单索引分片数维持在2-4个即可（每个分片对应15-20万条文档，刚好在Elasticsearch分片的高效运行区间）；
• 索引拆分策略：不要按天拆成1000条的小索引，而是用滚动索引+文档数阈值的方式——当某个索引的文档数达到35万左右时，自动创建新索引承接写入，旧索引只读。这样既避免了小索引的开销，又能把大数据量拆分成易管理的单元。

二、用ILM（索引生命周期管理）自动化全流程 #

ILM是Elasticsearch的核心工具，完美适配你的长期存储需求，能帮你自动搞定索引的创建、滚动、冷热分层、删除：

• 滚动策略：配置索引的文档数上限（比如35万）或磁盘大小上限（比如30GB，根据你的数据结构调整），达到阈值后自动生成新索引，旧索引停止写入；
• 冷热数据分层：把最近3个月内的热数据放在高性能节点（SSD、高内存CPU），保证搜索、排序的速度；把超过3个月的冷数据迁移到低成本机械硬盘节点，降低存储成本，同时冷数据设为只读，减少资源消耗；
• 自动删除：根据业务需求设置数据保留期限（比如1年），到期后ILM会自动删除整个旧索引——这比单文档删除高效太多，直接释放磁盘空间，不用等段合并清理。

三、优化搜索与排序的细节 #

在索引规划的基础上，再做这些细节优化：

• 字段优化：对不需要全文搜索的字段设为keyword类型，关闭无用字段的分词；排序字段确保开启doc_values（默认是开的，但可以检查下），减少排序时的计算开销；
• 查询优化：查询时尽量加上时间范围过滤，结合索引的命名规则（比如data-2024-week36）直接指定目标索引，避免跨大量索引的全量扫描；
• 排序优化：如果是大结果集排序，用search_after替代传统分页排序，避免深度分页的性能问题；不需要统计总命中数时，加上track_total_hits: false减少额外计算。

四、让删除操作更高效 #

• 优先按索引删除：利用ILM的自动删除策略，直接删除整个旧索引，这是Elasticsearch里最高效的删除方式——单文档删除只是标记删除，后续还要靠段合并清理，而删除索引是直接释放磁盘空间；
• 必要时的单文档删除：如果必须删单条文档，一定要用精准的查询条件（比如主键、唯一标识），避免全索引扫描；定期给冷数据索引做段合并（ILM可以自动配置），清理标记删除的文档。

五、生产环境的高可用调整 #

当前你用0副本，生产环境强烈建议至少设置1个副本：

• 副本分片可以分担搜索请求的压力，提升整体吞吐量；
• 主分片所在节点故障时，副本能自动升为主分片，保证服务不中断；
• 分片数尽量和节点数匹配，比如3个节点的话，单索引设3主3副，让分片均匀分布在各个节点，平衡负载。

总结 #

你的核心方案应该是：基于文档数阈值的滚动索引（结合ILM自动化）+ 2-4分片/索引（每个分片15-20万条）+ 冷热数据分层 + 自动生命周期管理。这个方案既保留了你实测的合理规模索引的性能优势，又能支撑6.58亿年数据的存储需求，同时兼顾搜索、排序、删除的高效性。

内容的提问来源于stack exchange，提问作者Palaniichuk Dmytro