我有一个大型的弹性搜索集群，其中包含10个以上的数据节点，并且托管了超过3000万个文档的多个索引。
现在，为了解决该群集上的性能问题，我开始查看一些索引的慢日志，并注意到以下奇怪的事情：
类型[estype]，统计信息[]，search_type [QUERY_THEN_FETCH]，total_shards [48]，
在这里，我的慢日志显示其命中了48个分片，这对我的索引来说是不可能的，因为它有6个主分片和3个副本，并且按照我的理解，如搜索类型中所述，它是一个普通的搜索查询，对于ES向主分片或副本分片发送请求，但不向两者都发送。
因此，根据此逻辑，它应该命中最大值，最大为6个分片，即使我认为它命中了所有分片（包括副本），也可以最大为6 * 4 = 24个分片，那么我的慢日志中的结果如何到了48岁，这使我对这些查询的缓慢性产生怀疑。
注意：-如果我只是从慢速日志中获取ES查询并直接使用kopf或curl进行命中，则作为响应，它仅显示正确的6个分片。
最佳答案
找到了原因，实际上在我们的应用程序中，我们创建了一个单独的基于语言的索引，并且它们具有相同的配置（没有分片和副本）。
当我签入应用程序时，总共有8个基于语言的索引（每个索引都有6个主要分片）。
我们发送给ES的查询使用索引名称中的（*），我们将索引名称模式设置为indexprefix_lang，因此foo_en，foo_gb，foo_es等等，因此通过在索引前缀中指定*就像这里foo_*一样，索引。这导致了8 * 6 = 48个碎片。
造成混淆的原因是，除英语以外，其他基于语言的索引的文档数量很少，并且未超过我们设置的慢查询阈值，并且以慢查询日志格式显示的索引名称为foo_en，但它显示整个查询的total_shards（与索引无关），在这种情况下为48。
关于performance - 了解Elasticsearch慢查询日志格式，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/58460286/