当 Elasticsearch 查询的 from + size 超过默认 10000 时，会触发 QueryPhaseExecutionException 错误；强行调大 index.max_result_window 存在性能与内存风险，推荐优先使用 Scroll API 或 Search After 实现高效大数据集遍历。
当 elasticsearch 查询的 `from + size` 超过默认 10000 时，会触发 `queryphaseexecutionexception` 错误；强行调大 `index.max_result_window` 存在性能与内存风险，推荐优先使用 scroll api 或 search after 实现高效大数据集遍历。
Elasticsearch 默认对深度分页（deep pagination）施加严格限制：from + size ≤ 10000。这是出于性能保护——例如请求第 2872980 条开始的 10 条数据（from=2872980&size=10），ES 需在每个分片上排序并加载前 2872990 个结果，再截取最后 10 条，极易引发 OOM 和响应延迟。
虽然可通过索引设置临时绕过限制：
PUT /bookings/_settings
{
"index.max_result_window": 100000000
}
⚠️ 但强烈不建议在生产环境普遍采用此方案：
- 内存开销随 from 线性增长，高并发深度分页将迅速耗尽 JVM 堆内存；
- 影响集群稳定性，尤其在多分片、大数据量场景下；
- 该设置仅对当前索引生效，无法解决根本性架构问题。
✅ 推荐替代方案（按优先级排序）：
1. 使用 Search After（推荐用于实时滚动/翻页）
基于排序字段的值进行游标式分页，无深度偏移开销，支持实时数据变更：
GET /bookings/_search
{
"size": 10,
"sort": [
{ "timestamp": { "order": "desc" } },
{ "_id": { "order": "desc" } }
],
"query": { "match_all": {} }
}
获取响应末尾的 sort 值（如 [1712345678900, "abc123"]），作为下次请求的游标：
GET /bookings/_search
{
"size": 10,
"search_after": [1712345678900, "abc123"],
"sort": [
{ "timestamp": { "order": "desc" } },
{ "_id": { "order": "desc" } }
]
}
2. 使用 Scroll API（适用于导出、批量处理等非实时场景）
适合一次性拉取全量或超大数据集，但不支持实时查询（快照语义）：
POST /bookings/_search?scroll=2m
{
"size": 1000,
"query": { "match_all": {} }
}
# 使用返回的 scroll_id 持续拉取
POST /_search/scroll
{
"scroll": "2m",
"scroll_id": "FGluY2x1ZGVfYWxs..."
}
? 补充说明：index.max_result_window 是索引级动态设置，无需重启；但修改后仅影响新写入的段（segments），已有数据无需重建。不过，请始终将它视为最后手段，而非分页方案。
总结：解决 Result window is too large 的核心不是“调大阈值”，而是摒弃传统 from/size 分页思维，转向更符合分布式搜索特性的 search_after 或 scroll。这既是性能最佳实践，也是 Elastic 官方明确倡导的数据访问范式。
