1、首先确定集群的健康

1）_cat/health?v

2）检查集群健康的cpu ，io，内存，磁盘等指标是否都正常

2、慢查询可能的原因（case by case）

2.1 shards大小不合理

遇到这么一个案例：

1、客户反馈es集群存在很多慢查询，检查发现都是term查询，而且进行了sort排序，但是size是top 15，这样的查询不至于一直报慢查询。

2、继续检查日志，发现所有慢查询都是一个索引报的，也就是其他的索引的查询都是正常的

3、定位到索引后，_cat/shards/index_name?v  。五个分片一个副本，shards的store：58G。大小不合理，导致慢查询，建议reindex索引，增加分片数。删除旧索引，给新索引建以旧索引名称为名的别名。

tips：reindex期间，索引仍能都能写，reindex启动的那一刹会定格一个快照，所以建议reindex期间，建议停止索引的写入。避免新旧索引数据不一。

reindex会对源索引的有一定的io开销，相当读取源索引的所有数据再写入到新的索引中，建议尽量在业务低峰期做操作。

2.2 term的字段是数值类型，查询字段非常庞大

数值型byte、short、integer、long做term查询构造docid集合的bitset很费时

如果数值字段没有range需求，改为或者再插入一个keyword类型字段https://elasticsearch.cn/article/446， 如果是cardinality聚合&高基数，可以写入时提前prehash(https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-metrics-cardinality-aggregation.html#_pre_computed_hashes)

PS：是否逻辑 的byte字段建议直接用boolean，不过byte类型的额外好处是如果需要true/ false之外的第三种状态，扩展更方便；如果继续使用byte类型，参考： 数值字段(long/ integer)没有range和agg聚合需求，改为或者再插入一个keyword类型字段

按照：https://elasticsearch.cn/article/446

2.3 prefix、wildcard、regexp

通配符和正则表达式、模糊查询，需要遍历倒排索引中的词条列表来找到所有的匹配词条，然后逐个词条地收集对应的文档id

慢日志出现prefix、wildcard、regexp避免使用左通配这样的模式匹配（如： *foo 或 .*foo 这样的正则式；对于部分输入即提示的应用场景，可以考虑优先使用completion suggester, phrase/term suggeter一类性能更好,模糊程度略差的方式查询（https://elasticsearch.cn/article/171）；考虑用ngram tokenizer替代(https://www.elastic.co/guide/en/elasticsearch/reference/6.7/analysis-ngram-tokenizer.html#analysis-ngram-tokenizer) 和 (https://wjw465150.github.io/Elasticsearch/3_2_DeepSearch.html#%E8%B6%8A%E8%BF%91%E8%B6%8A%E5%A5%BD)

2.4 agg聚合查询

agg，聚合文档多，多重聚合、条件复杂，深度翻页，from和size很大

优化聚合, 查看collect mode 、execution hint和Minimum document count小结  https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-terms-aggregation.html

2.5 from和size大于10000

深翻页，需要对每个shard的返回的数据整合取top，总条数是shards* (from+size)，非常消耗cpu和内存

用 scroll或search_after替代(http://doc.codingdict.com/elasticsearch/109/， http://doc.codingdict.com/elasticsearch/117/)

2.6 script，此外hot_thread显示消耗在script上

script，脚本性能相对低些.

避免使用脚本计算动态字段，建议在索引时计算并在文档中添加该字段；避免进行复杂的计算

2.7 nested, mapping中也有nested

nested查询, 对doc的每一个nested field都会生成一个独立的document, 这将使doc数量剧增，影响查询效率。

2.8 has_child或has_parent, mapping中也有_parent

parent-child查询，适合适合于父文档少、子文档多的情况，比nested慢5到10倍(https://www.elastic.co/guide/cn/elasticsearch/guide/current/parent-child-performance.html）

ps：抄自大佬的文章，我自己也是没有吃透的。mark一下