问题背景
在用户的实际使用中发现，某一简单查询，查询一段时间内符合要求的记录，查询老旧数据，响应速度在1秒左右，而查询包含最近数据的同类查询则慢到十秒左右，且存在超时的现象。老旧数据比如说今年5月份之前的数据，新数据比如说今年6月份的数据，对比的查询仅仅只有时间段的差异，没有排序，也没有模糊匹配。
另外，在出现慢查询时，CPU利用率几乎飙升到100%。
问题分析
是分片的存储倾斜导致的吗？
用户的数据量有几十TB，几百亿条数据。首先是怀疑分片分配或者存储不均匀的问题导致，而现场的实际是该索引一共设置了1000分片，此后未再设计按月份存储拆分索引这种操作，也就是所谓5月份或者6月份的记录数据都是叠放在相同的索引分片中，均匀分散在1000个分片里，新老数据不存在分布的区别，这边从两份查询结果命中的分片数相等也可见一斑。
是新数据段尚未合并导致的吗？
新的索引数据写入时， ES会创建新的段，通过后台的实际检测发现，随机抽取了一个分片目录，里面共有200+的文件数，其中数据段的数量在80+，属于较多的情况。因此首先考虑执行一下段合并。
通过Kibana执行POST强制合并的请求时，往往会报请求超时的错误，这时无需去调大超时时间。因为这个调用将阻塞直到合并完成。如果http连接丢失，请求将在后台继续进行，任何新的请求将被阻止，直到之前的强制合并完成。
等到观察到合并执行结束后，再去尝试比较查询速度，绝对速度略有提升，但相对速度仍然有数倍的差异。方向对了，但不全对，问题的根因不在于此。
查询缓存的影响？
如此巨大的速度差异，可能是ES查询缓存引起的。
进行了一些简单的查询顺序调换，得到的结果仍然是查询最新的数据较慢。同时也发现，对慢查询直接进行第二次查询的时候，速度确实特别快，从十秒到低于1秒，这应该是直接使用缓存的效果了。
那么也不是由于缓存引发的。但这里没有拿到一手完整的数据，存疑。
分析总结
这种现象的原因可能是：
- Segments（段）：ES将索引划分为多个段，每个段包含部分文档。当新文档被添加到索引中时，ES会创建新的段。老数据存在于旧的段中，而新数据存在于新的段中。查询旧数据比查询新数据快是因为旧的段被更频繁地访问和缓存，而新的段可能还没有被完全加载或缓存，导致查询速度较慢。
- Merge（合并）操作：ES的合并操作会将多个段合并为一个更大的段，以优化查询性能。当有新文档被索引时，ES需要执行合并操作来压缩段数量。这个合并操作可能会导致查询新数据较慢，因为在合并过程中，旧的段可能会被频繁地访问和缓存，而新的段可能需要等待合并完成才能被加载和缓存。
- Refresh（刷新）操作：ES默认每秒执行一次刷新操作，将内存中的数据写入磁盘。当有新文档被索引时，ES需要等待下一次刷新操作才能将新数据写入磁盘并更新索引。因此，在刷新操作之前查询新数据可能会较慢，而查询旧数据不会受到影响。
为解决以上问题，可以采取以下措施：
- 提高刷新频率：可以通过调整刷新间隔来减少新数据查询的延迟，但会增加写入操作的开销。
- 使用更少的段：可以通过手动触发合并操作来减少索引中的段数量，从而提高查询性能。
- 预热（warm-up）：可以在索引启动前对新数据执行一些查询操作，以提前加载和缓存新数据所在的段，从而加速后续查询。
- 设置查询优先级：可以通过设置查询优先级，给新数据的查询分配更多的资源和处理能力，以提高查询速度。
总结来说，ES查询老数据较快、查询新数据较慢是由于ES的索引段划分、合并操作、刷新操作等机制导致的，通过调整刷新频率、优化段合并、预热和设置查询优先级等方法可以改善新数据查询的性能。
解决方案
现场的读写参数等不便进行调整，因此我从优化查询语句入手，发现业务的查询只涉及3个字段，分别是2个term和一个range查询，这种查询是无需进行评分的。因此推荐将query语句的must查询改为了filter查询，查询慢的问题迎刃而解，所有时间段的查询都得以秒回。
