search的运行机制当node3收到用户请求时，首先执行查询阶段。此时协调Node角色node3从6个主从shard中随机选择3个shard，发送Search，被选中的shard将分别执行查询和搜索，返回from+size的文档id和sort值node3综合了from+size三个分片返回的documentid，根据sort值排序并选择from到from+sizeDocumentidcorrelationscore相关分值在分片之间是独立的，也就是说同一个term的idf等价值在on上是不同的不同的碎片。与分片有关。当文档数量较少时，会导致相关分数严重不准确。解决方案将分片数设置为1，从根本上解决问题。当文档不多时可以使用这种方法。比如百万到千万级别的文档数，使用dfsquery-then-fetch的查询方式。dfs获取所有文档重新计算相关分数需要更多的CPU和内存资源，性能较差，所以一般不推荐。排序将默认使用相关分数进行排序。用户可以指定排序字段来设置排序规则。按字符串排序比较特殊，因为es有text和keyword两种类型。text类型的排序过程本质是对字段的原始内容进行排序在排序的过程中，倒排索引在这个过程中无法发挥作用，需要使用正向索引，即原始通过文档id和字段可以快速获取字段内容。es为此提供了两种实现方法。fielddata默认是禁用的，docvalues是默认启用的，除了文本类型fielddata是通过api启用的。这时候，字符串按照分词后的term进行排序，结果往往很难合并。对分词进行聚合分析时，一般会启用期望。默认情况下启用值。创建索引的时候有关系。如果需要再次开启，则需要进行reindex操作。该字段可用于获取存储在fielddata或doc值中的内容。案例中如何获取前1000个文档当获取990-1000个文档时，每个shard上会获取1000个文档，然后coordinationnode会聚合所有shard的结果，然后对前1000页进行排序。页数越深，处理的文档就会越多，占用的内存也就越多，耗费的时间也就越多。尽量避免深度分页。ES使用index.max_result_window限制最多10000条数据。滚动文档集合的api使用快照来避免深度分页的问题，不能用于实时搜索，数据不是实时的尽量不要使用复杂的排序条件，使用_doc有点麻烦为了最高效使用search_after避免深度分页的性能问题提供实时下一页文档获取功能缺点不能使用from参数，即不能指定页数只能跳到下一页，不能跳到上一页使用简单的普通搜索但指定排序值并保证值唯一使用上一个文档的排序值上一步查询如何避免深度分页的问题如何通过唯一排序定位到每次处理的文档数控制在size内
