Elasticsearch scroll 滚动查询和搜索上下文有哪些核心特点？
scroll 滚动查询是什么？为什么需要它？
Elasticsearch 的标准分页（from + size）在深度分页时性能急剧下降——获取第100页时，每个分片都要检索前1000+条数据，协调节点再做全局排序。ES 默认限制 from + size 不超过 10000（index.max_result_window）。
scroll 滚动查询就是为解决这个问题设计的：它发起一次查询后，在服务端创建一个搜索上下文快照，后续通过 scroll_id 逐批拉取数据，无需重复排序。
核心机制：
- 快照语义：scroll 返回的是发起查询时刻的索引快照，之后的文档增删改不会影响结果
- 两阶段搜索：首次请求执行 Query（获取文档ID列表）+ Fetch（拉取文档内容），后续滚动请求只做 Fetch
- 有状态：scroll_id 在服务端持久化，直到超时或显式清除
// 1. 初始化 scroll 查询 GET /products/_search?scroll=5m { "size": 1000, "query": { "match_all": {} } } // 2. 使用 scroll_id 继续拉取 GET /_search/scroll { "scroll": "5m", "scroll_id": "FGluY2x1ZGVfY29udGV4dF91dWlk..." } // 3. 清除 scroll 上下文（重要！） DELETE /_search/scroll { "scroll_id": "FGluY2x1ZGVfY29udGV4dF91dWlk..." }
适用场景： 数据导出、reindex 重建索引、ETL 批量处理等离线任务。
不适用场景： 实时分页请求——scroll 上下文占用堆内存，长时间不清理会导致资源泄漏。
搜索上下文（search context）是什么？
每次 _search 请求都会创建搜索上下文，它维护了查询生命周期内的状态，包括：
- Query 阶段的匹配文档ID列表
- 排序、聚合、高亮等操作所需的中间状态
- 请求级别的缓存信息
关键特征：
- 普通搜索的上下文在请求结束后自动销毁
- scroll 查询的上下文会持续存活直到超时
- 上下文数量受
search.max_open_scroll_context限制（默认500）
搜索上下文本身不是一种"查询方式"，而是 scroll、聚合、高亮等功能的底层支撑。面试中常把"搜索上下文"和"scroll 上下文"混谈，核心区别在于生命周期：前者随请求结束而销毁，后者由 scroll 参数控制存活时间。
scroll、search_after、from+size 三种分页怎么选？
| 对比维度 | from + size | scroll | search_after |
|---|---|---|---|
| 原理 | 偏移量跳过 | 快照 + 游标批量拉取 | 排序值游标逐页前进 |
| 状态 | 无状态 | 有状态（服务端保存快照） | 无状态 |
| 深度分页性能 | 差（O(n)排序开销） | 好（一次排序分批取） | 好（基于排序值定位） |
| 实时性 | 实时 | 快照，不反映后续变更 | 实时 |
| 随机跳页 | 支持 | 不支持 | 不支持 |
| 资源消耗 | 深分页时高 | 占用堆内存直到超时 | 低 |
| 典型场景 | Top N 查询 | 批量导出/重建索引 | 实时深度分页 |
选择建议：
- 数据量小、页码浅：
from + size，简单直接 - 批量离线处理：
scroll - 实时深度分页：
search_after - 需要一致性视图 + 实时分页：
search_after+ PIT（Point in Time）
Sliced Scroll 如何提升并行处理效率？
单条 scroll 串行拉取大量数据时效率有限。ES 提供 Sliced Scroll，将一个 scroll 查询切分为多个切片，并行拉取：
GET /products/_search?scroll=5m { "size": 1000, "slice": { "id": 0, "max": 4 }, "query": { "match_all": {} } }
max 为切片总数，id 为当前切片编号（0 到 max-1）。每个切片独立返回一部分数据，多个线程/进程可并行拉取不同切片，显著缩短总耗时。
注意： 切片数不宜超过分片数，否则部分切片无数据可返回。
面试高频追问
Q1: scroll 的 scroll_id 会变吗？ 会。每次滚动请求返回新的 scroll_id，客户端应始终使用最新返回的值。
Q2: 忘记清除 scroll 上下文会怎样？
上下文会持续占用堆内存直到超时。大量未清除的上下文可能导致 OOM，生产环境务必在处理完成后调用 DELETE /_search/scroll 清理。
Q3: PIT + search_after 和 scroll 有什么区别？ PIT（Point in Time）也创建快照，但更轻量，与 search_after 配合可实现一致性视图的实时分页。scroll 适合一次性全量遍历，PIT + search_after 适合交互式逐页浏览。ES 7.10+ 推荐用 PIT 替代 scroll 做深度分页。
Q4: scroll 查询期间索引发生变更怎么办？ scroll 基于快照，索引变更不影响已发起的 scroll 结果。但新文档不会出现在结果中，已删除文档可能仍存在——这取决于快照创建时机。