使用 gopkg.in/olivere/elastic.v2 时，无法通过增大 Size() 获取全部结果（易触发内存或超时错误），正确方式是采用滚动查询（Scroll API）分页拉取，避免深度分页性能问题。
使用 `gopkg.in/olivere/elastic.v2` 时，无法通过增大 `size()` 获取全部结果（易触发内存或超时错误），正确方式是采用滚动查询（scroll api）分页拉取，避免深度分页性能问题。
在 Elasticsearch 中，直接将 Size 设置为极大值（如 Size(10000) 或更高）不仅可能触发 query_phase_execution_exception 或 circuit_breaking_exception，还会因 Lucene 底层的 from + size 深度分页机制导致显著性能下降——Elasticsearch 需为每页加载并跳过前 from 条文档，当 from 过大时开销呈线性增长。
因此，获取全部匹配文档的推荐方案是使用 Scroll API。它专为大批量、顺序读取场景设计：首次请求初始化一个快照式上下文（snapshot-based context），后续请求仅按批次拉取结果，不依赖排序偏移，性能稳定且内存可控。
以下是基于 elastic.v2 的完整滚动实现示例：
import (
"context"
"encoding/json"
"io"
)
termQuery := elastic.NewTermQuery("item_id", item_id)
scroller := es.client.Scroller().
Index(index).
Type(SegmentsType).
Query(termQuery).
Sort("time", true). // 注意：scroll 要求 sort 必须明确指定，且不能含 _score（除非显式启用 track_scores）
Size(100). // 建议设为 100–1000，平衡网络往返与单次内存占用
var allItems []map[string]interface{}
for {
res, err := scroller.Do(context.TODO())
if err == io.EOF {
break // 所有文档已读取完毕
}
if err != nil {
return nil, err // 实际项目中应记录日志并做重试/降级处理
}
for _, hit := range res.Hits.Hits {
if hit.Source == nil {
continue
}
var item map[string]interface{}
if err := json.Unmarshal(*hit.Source, &item); err != nil {
// 可选择跳过损坏文档或记录警告
continue
}
allItems = append(allItems, item)
}
}⚠️ 关键注意事项：
-
Scroll 上下文有效期：默认
1m，可通过.Scroll("5m")显式延长，避免因处理耗时过长导致上下文过期（SearchContextMissingException）； -
排序字段必须确定：
Sort()必须指定非_score字段（或启用TrackScores(true)），否则 scroll 无法保证结果一致性； - 不适用于实时性要求高的场景：scroll 基于搜索时的索引快照，期间新写入/更新文档不可见；
-
资源清理：虽
elastic.v2在io.EOF后自动清除 scroll 上下文，但在异常退出路径中建议手动调用scroller.Clear()（需升级至 v5+ 或自行封装）； -
替代方案提示：若需实时、可跳转的全量遍历，可考虑
search_after（配合游标分页），但需客户端维护状态；对极小数据集（Count() 判断后决定是否走 scroll。
综上，滚动查询不是“魔法开关”，而是 Elasticsearch 大数据量导出与批量处理的标准实践。合理配置 Size、监控 scroll 生命周期、妥善处理解析异常，即可稳健支撑千万级文档的可靠拉取。
