注意ES的默认排序和慎用_doc排序

这两天遇到了一个坑，就是ES的默认排序，对于我们有时候直接把ES当数据库来玩的时候，往往返回的结果的_score都是0, 而ES默认的排序，恰恰就是按 _score的desc。

那么，在全部doc的_score 都是0分的时候，分页就会错乱，有时候出现在第一页的结果很可能会重复出现在第二页，第三页 （取决于当时shards 返回的结果的顺序。

好了，有些人会觉得，为了提高性能，又不care排序的顺序的话，可能会立刻想到用_doc排序。包括我也是这么想的，那么结果告诉你，这也是会有问题的。
我们先看看_doc的描述：

也就是说，我们简单理解，_doc 其实就是按照Lucene 文件结构的当时索引时的先后顺序，那么按道理它就是最快的，可是，别忘了，ES是分布式的，也就是说，这里有很多个Lucene，这个_doc 在一个shard 里它是唯一的，可是在ES集群则不然，比如一个doc1 在shard A 上是2 ，那么它的_doc就是2， 可是有可能doc5 在shard C上也是2，因此他们两个的_doc值是一样的，也就是说还是避免不了排序上的先后，只不过这种几率会减少了很多。

其实,_doc 仅用在scroll scan下是有意义的， 因为scroll的scan 是直接按Lucene全量导，而按Lucene的文件系统先后顺序来导是最快的，在其他场景记得慎用。

关于_id与_uid

6.0版本之前和之后是不一样的。
6.0版本之前是这样子的：

那么想对不打分的文档做排序的话怎么办好呢，有人也会想到_id, 好的，_id其实是可以的，只不过，如果你想排序的话，可以考虑用 _uid去代替 _id，_id是不支持排序的,因为_id默认是not index的，而uid其实是一个 _type + _id的字符串。

6.0版本及之后是这样子的：
从6.0版本开始，_id会被建索引，也可以支持aggregate和sort了，_uid不再单独存在，而是_id的别名。
如果要按_id排序，不建议直接用_id，而是可以拷贝_id值到另一个新字段，新字段启用docvalue，这样可以节省内存使用。


转自链接，有修改：https://www.jianshu.com/p/bdf98307d984