Elasticsearch分片配置、搜索及multi-search速度优化咨询

你最初计划的每副本5分片、总计10分片的方案属于过度分片，不仅无法提升搜索速度，反而会增加协调节点调度、结果合并的额外开销，拉低整体查询性能。
结合当前集群架构和索引规模，最优配置为主分片数设为2，保留1副本规则，总分片数为4：

• 配置生效后每个节点会均匀落2个分片（1主1副本），单分片大小约14GB，完全落在Elasticsearch 10GB-30GB的单分片最优性能区间，既不会因为分片过大导致段扫描、合并耗时过长，也不会因为分片过多产生不必要的调度开销。
• 2节点架构下分片数不是越多越好：如果硬上10分片，单分片容量仅5.6GB，查询时协调节点需要向多一倍的分片分发请求、合并返回结果，当单节点承载的分片数超过CPU核数1.5倍时，分片并行查询的优势会完全消失，甚至比少分片配置慢30%以上。

• 索引层优化：将products索引中不需要参与检索、过滤、聚合的字段index属性设为false，不需要返回给前端的字段加入_source排除列表，减少磁盘IO和内存占用；高频过滤、排序的字段优先用keyword类型开启doc_values，高频聚合的keyword字段开启eager_global_ordinals，避免首次查询加载词典的冷启动延迟；对不再写入的历史冷数据执行POST /products/_forcemerge?max_num_segments=1，减少查询时需要扫描的段数量，注意有持续写入的热索引不要执行该操作，会大幅抬升写入IO压力。
• 查询层优化：禁止使用前缀通配的模糊查询（如*关键词），这类查询无法走倒排索引，会触发全字段扫描；查询时明确指定_source返回字段列表，禁止全量拉取文档内容；深度分页场景（查询偏移量超过10000）弃用from+size方案，改用search_after做游标滚动；所有不需要计算相关性得分的过滤逻辑全部放入filter上下文，充分利用查询缓存提升重复查询速度。
• 集群层优化：JVM堆内存设置为节点物理内存的50%，最高不超过32GB，剩余内存全留给操作系统做文件系统缓存，尽量让products索引的热数据全部命中文件缓存，查询速度可提升5-10倍；禁止Elasticsearch节点和其他高内存、高IO占用的服务混部。

• 控制单次请求的子查询数量：单次_msearch携带的子查询数建议控制在10个以内，不要一次批量塞几十上百个子查询，协调节点需要完成所有子查询的解析、分发、结果合并，子查询过多会直接导致协调节点CPU、内存打满。
• 排查拖后腿的慢子查询：大部分_msearch慢不是接口本身的问题，而是请求里混杂了全表扫描、大基数聚合、深度分页的低效子查询，可以用profile API定位每个子查询的耗时瓶颈，单独优化低效子查询后整体耗时会明显下降。
• 调整并发参数：给_msearch请求显式设置max_concurrent_shard_requests参数，值和单节点CPU核数保持一致，不要用默认值5，避免分片请求并发过高打满节点IO，或者并发不足浪费CPU资源。
• 分离节点角色：如果_msearch请求占比高、并发大，建议单独部署2台低配协调节点专门承接查询请求，不要让数据节点同时承担数据存储、请求调度、结果合并的压力，2节点架构下加2台低配协调节点，_msearch性能通常能提升40%以上。

内容的提问来源于stack exchange，提问作者asela kotagama