Elasticsearch 5.x 源码分析（12）对类似枚举数据的搜索异常慢的一种猜测

2017-1-9 更新： https://elasticsearch.cn/article/446 why this happened? 携程的兄弟给出了答案，看来结论是一致的就是number在构造scorer时，实际上是构造一个巨大的bitset并在上面生成一个迭代器。而keyword 在做链表时有跳表查询显然找docid要快好多。 根源就在于Lucene 6.0 对于存储number类型是用k-d tree 造成的。

看来携程的高手看Lucene还是看的很深，需要努力学习！

后贴出作者给出的结论，如果一定要用number建索引而又不用range操作的，赶紧升级到5.4 吧：

小结: 在ES5.x里，一定要注意数值类型是否需要做范围查询，看似数值，但其实都是做Term或者Terms匹配的，应该定义为keyword字段。 如果RangeQuery的结果集很大，并且还需要和其他更加selective的查询条件做AND的，应该升级到ES5.4+，该版本在底层引入的indexOrDocValuesQuery，可以极大提升该场景下RangeQuery的查询速度。

近因为一个索引的数据量日益暴增，达到8，9亿，因此相应的慢查询也开始显现，针对其中几种查询更是慢的离谱。 查看了一下这个慢查询的搜索条件其实也很简单，而且，简单到离谱，其中有这么两个条件查询，这两个字段的mapping都是short 类型，在没有这两个条件的查询，延迟是可以接受的，仍然能保持200ms级以内，而 is_deleted 则去到数百毫秒，is_warmup则是暴增到1~3s 不等。