Elasticsearch的查询慢的问题往往是由多种因素造成的，同时我们也需要遵循Elasticsearch的查询准则：ES适合top N的查询，不适合大数据量返回的查询。
场景1 内存参数配置不合理，文件系统缓存不足。
记得给你的Elasticsearch预留一定的内存给Lucene文件缓存使用哦。
场景2 查询范围过大，一次查询过多的分片，如全表扫描查询。
一次查询过多的分片，容易把内存撑爆，so，最好分批次查询，温柔点嘛。
场景3 进行深度翻页查询，如查询10000之后的结果。
进行深度翻页查询，如查询10000-10010的结果，这时候需要使用scroll查询了。
场景4 查询返回的结果集过大，如10w。
同样，这种查询太暴力了，建议使用scroll查询分批次返回，Elasticsearch没你想象的坚强。
场景5 查询语句不是最优，如过滤查询可以使用filter。
根据具体的业务场景去优化查询语句，过滤查询使用filter，不需要评分，减少很多计算。
场景6 使用模糊匹配查询造成内存溢出的问题。
千万不要尝试使用*等通配符的暴力做法，内存很脆弱的。
场景7 聚合查询返回的结果集过大，聚合的范围过大。
聚合更加是耗费内存的操作了，所以你懂的。
场景8 聚合查询N多唯一值引起的高内存使用率。
同上，慎重。
场景9 用text字段进行排序，造成fielddata占用大量的内存。
排序请用keyword字段，谢谢。
场景10 索引段文件过多，需要定时的进行索引段合并。
查询的底层文件是lucene段文件，减少段文件个数一定程度上可以减少并发查询的段文件个数。
场景11 分片分布不均衡，未能充分利用机器资源。
尽量让分片均匀分片，查询的时候才能充分发挥分布式的优势。
场景12 磁盘IO瓶颈。
没办法，加钱吧？
场景13 索引数据结构mapping设计不合理，如不需要分词的keyword。
mapping设置超关键的，建立索引之前慎之又慎，切记。。。
场景14 分词器设计不合理，如存在过度分词的问题。
是的，如果你的字段分的越多，需要遍历的term就更多，查询肯定就更慢了呀。
场景15 索引分片过大，如单个分片达到100GB+。
单个分片这么大，你考虑过机器的感受吗，建议单个分片20-50GB大小。
前言经常会有人吐槽，Elasticsearch为什么查着查着突然就慢了？笔者总结了常见的一些导致查询慢的场景，供大家排查。go go goElasticsearch查询慢问题排查思路Elasticsearch的查询慢的问题往往是由多种因素造成的，同时我们也需要遵循Elasticsearch的查询准则：ES适合top N的查询，不适合大数据量返回的查询。场景1 内存参数配置不合...
日志分析功能，因为它们不保存数据（索引/分片）。Slowlogs有助于回答以下问题：
Slowlogs专门用于分片级别，这意味着只应用数据节点。仅协调 Coordinating-only/客户client节点不具备
