事由
应用部门反应搜索中间件，响应速度偶然过慢，查询搜索日志发现不定时会有超过2s的响应。
排查
分析DSL，看下DSL是否使用不当，一番检查后没有发现DSL异常。使用Search Profiler分析DSL，结果如下图：
status=0 这个条件竟然使用了10.5ms 并且status类型是int 使用term查询，结果超乎想象。
分析问题
为什么number类型的竟然需要查询那么久，生产环境使用的ES是5.6.5,lucene是6.6.1，一番搜索后发现lucene6.0以上版本引入了重新设计的数值类型的索引结构，不再采用倒排索，而是使用了更适合范围查找的Block K-d Tree， ES从5.0开始引入这种新结构。
Term Query由于通常非常快，从5.1.1开始不再被缓存到Query Cache
感兴趣的可以看下这篇文章numb3rs
确定解决方案
因status只是用来标记状态的字段，并不会用作范围查找，而且status的值也就只有那么几种，比较适合使用keyword来存储。
优化
把status改为keyword结构后，搜索效率有一个质的飞跃
建议，不做范围查找的字段都设置为keyword类型。
参考
https://elasticsearch.cn/article/446