查询服务超时
我们有时候写查询，为了图方遍，经常使用通配符*来查询，这有可能会匹配到多个索引，由于索引下分片太多，超过了集群中的核心数。就会在搜索线程池中造成排队任务，查询慢

主机CPU飙高也会查询慢

另一个常见原因是磁盘 I/O 速度慢，导致搜索排队或在某些情况下 CPU 完全饱和。
除了文件系统缓存，Elasticsearch 还使用查询缓存和请求缓存来提高搜索速度。 所有这些缓存都可以使用搜索请求进行优化，以便每次都将某些搜索请求路由到同一组分片，而不是在不同的可用副本之间进行交替。这将更好地利用请求缓存、节点查询缓存和文件系统缓存。
还有就是，ES做性能优化等等

Elasticsearch会为每个field都建立了一个倒排索引，张三、李四、23、24…这些叫term，而[1,4]就是Posting List。Posting list就是一个int的数组，存储了所有符合某个term的文档id。

通过posting list这种索引方式似乎可以很快进行查找，比如要找age=24的同学，很快就会找到，id是1，4的同学。但是，如果有上千万的记录呢？如果是想通过name来查找呢？所以需要将Term进行排序

Term Dictionary
Term Dictionary：为了快速找到某个特定的term，将所有的term进行排序。再采用二分查找法查找term。时间复杂度logN
看起来，似乎和mysql数据库通过B-Tree的方式类似。而且Elasticsearch直接通过内存查找term，不读磁盘，但是如果term特别多的话，term dictionary也会很大，将所有的term dictionary都缓存到内存里是不太现实的。

Term Index
它包含的是term的一些前缀。所以term index 占用的空间只有term的的几十分之一。在内存里可以放更多的term index。缓存所有的term index到内存里是可以的。
Term Index，就像字典里的索引页一样，A开头的有哪些term，分别在哪页，可以理解term index是一颗树