Elasticsearch "Result window is too large" 錯誤解決方案與深度優化建議

錯誤現象

執行搜尋查詢時拋出異常：

QueryPhaseExecutionException[Result window is too large, from + size must be less than or equal to: [10000] but was [10200].
See the scroll api for a more efficient way to request large data sets.
This limit can be set by changing the [index.max_result_window] index level parameter.]

ES 預設限制 from + size ≤ 10000，請求 10200 筆超出上限。

快速修復：調大 index.max_result_window

curl -XPUT "https://localhost:9200/your_index/_settings" -H 'Content-Type: application/json' -d'
{
  "index": {
    "max_result_window": 100000
  }
}'

• 將上限調大至 10 萬（視業務與硬體調整）。
• 修改即時生效，無需重啟節點。

根本原因與最佳實踐

為何 ES 要限制 10000？

深分頁（大 from）需在每個分片收集 from + size 文檔，再合併排序，消耗大量 CPU/記憶體/網路，易導致 OOM 或長尾延遲。

推薦替代方案

Search After 範例

GET /products/_search
{
  "size": 10,
  "query": { "match_all": {} },
  "sort": [ { "price": "asc" }, { "_id": "asc" } ],
  "search_after": [ 100, "product_50" ]  // 上一頁最後一筆的排序值
}

調大參數的風險提示

• 記憶體壓力： 深分頁會在堆外/堆內佔用大量緩衝區。
• 集群穩定性： 並發深分頁查詢可能拖垮整個叢集。
• 建議： 僅在無法改用 Scroll/Search After 且數據量可控（如 < 5 萬）時調大；生產環境務必壓測驗證。

總結

「治標」調大 max_result_window，「治本」改用 Scroll 或 Search After。根據業務場景選擇正確分頁策略，才是 ES 高效穩定的關鍵。