有几个 查询参数可以影响搜索过程。
偏好这个参数 preference 允许 用来控制由哪些分片或节点来处理搜索请求。 它接受像 _primary,
_primary_first, _local, _only_node:xyz, _prefer_node:xyz, 和
_shards:2,3 这样的值, 这些值在
{ref}/search-request-preference.html[search preference]
文档页面被详细解释。
但是最有用的值是某些随机字符串，它可以避免 bouncing results 问题。
想象一下有两个文档有同样值的时间戳字段，搜索结果用 timestamp 字段来排序。
由于搜索请求是在所有有效的分片副本间轮询的，那就有可能发生主分片处理请求时，这两个文档是一种顺序，
而副本分片处理请求时又是另一种顺序。
这就是所谓的 bouncing results 问题: 每次用户刷新页面，搜索结果表现是不同的顺序。
让同一个用户始终使用同一个分片，这样可以避免这种问题，
可以设置 preference 参数为一个特定的任意值比如用户会话ID来解决。
通常分片处理完它所有的数据后再把结果返回给协同节点，协同节点把收到的所有结果合并为最终结果。
这意味着花费的时间是最慢分片的处理时间加结果合并的时间。如果有一个节点有问题，就会导致所有的响应缓慢。
参数 timeout 告诉 分片允许处理数据的最大时间。如果没有足够的时间处理所有数据，这个分片的结果可以是部分的，甚至是空数据。
搜索的返回结果会用属性 timed_out 标明分片是否返回的是部分结果：
...
"timed_out": true, (1)
...-
这个搜索请求超时了。
|
Warning
|
超时仍然是一个最有效的操作，知道这一点很重要； 很可能查询会超过设定的超时时间。这种行为有两个原因：
|
在 [routing-value] 中, 我们解释过如何定制参数 routing
，它能够在索引时提供来确保相关的文档，比如属于某个用户的文档被存储在某个分片上。
在搜索的时候，不用搜索索引的所有分片，而是通过指定几个 routing 值来限定只搜索几个相关的分片：
GET /_search?routing=user_1,user2这个技术在设计大规模搜索系统时就会派上用场，我们在 [scale] 中详细讨论它。
缺省的搜索类型是 query_then_fetch 。 在某些情况下，你可能想明确设置 search_type 为 dfs_query_then_fetch 来改善相关性精确度：
GET /_search?search_type=dfs_query_then_fetch搜索类型 dfs_query_then_fetch 有预查询阶段，这个阶段可以从所有相关分片获取词频来计算全局词频。
我们在 [relevance-is-broken] 会再讨论它。