一、深度分頁：是什么？為什么會出現問題？

1.1 什么是深度分頁

• 查詢耗時隨頁碼深度?指數級增長?；
• 內存與 CPU 資源消耗劇增；
• 超過閾值后直接被 ES 拒絕。

1.2 ES 分頁的底層執(zhí)行機制（from + size）

ES 是分布式搜索引擎，數據分布在多個分片上。標準分頁（from + size）的執(zhí)行流程如下：

1. ?請求分發(fā)?：協調節(jié)點將查詢廣播至所有分片；
2. ?分片執(zhí)行?：每個分片獨立查詢并返回 前 from + size 條記錄 到內存；
3. ?結果匯總?：協調節(jié)點收集所有分片的結果（共 N × (from + size) 條）；
4. ?二次排序 + 裁剪?：全局排序后，僅保留 [from, from + size) 區(qū)間的數據返回。

核心痛點?：當 from = 10000, size = 100 時，每個分片需加載 10100 條數據，協調節(jié)點需對 所有分片的 10100 條 進行全局排序——最終卻只返回 ?100 條?！資源浪費極其嚴重。

1.3 ES 的保護機制：max_result_window

為防止 OOM，ES 默認設置：

index.max_result_window = 10000

即 from + size ≤ 10000，否則拋出異常。

示例：每頁 20 條 → 最多翻到第 ?500 頁?；

可通過以下方式修改（?不推薦隨意調大?）：

PUT /your_index/_settings
{
  "index.max_result_window": 20000
}

1.4 為什么不能簡單調大max_result_window？

調大閾值只是 ?**“掩蓋問題”**?，而非解決問題：

• 分片仍需加載大量數據到堆內存；
• 協調節(jié)點排序壓力劇增，極易觸發(fā) Full GC 或 OOM；
• 分布式環(huán)境下，分片越多，性能衰減越快。

二、ES 三大分頁方式深度對比

2.1from + size：基礎但危險

語法示例

GET /index/_search
{
  "query": { "match_all": {} },
  "from": 0,
  "size": 10
}

適用場景

• 小數據集（≤10000 條）；
• PC 端支持 隨機跳頁 的搜索（如百度、京東）；
• 后臺管理系統(tǒng)。

限制

• ?絕對不可用于深度分頁?；
• 超過 max_result_window 直接失敗。

2.2scrollAPI：全量遍歷的“老方案”

核心原理

• 首次查詢創(chuàng)建 ?數據快照?（snapshot）；
• 后續(xù)通過 scroll_id 獲取下一批數據；
• 快照基于首次查詢時刻，?后續(xù)寫入不可見?。

使用流程

?首次查詢?（帶 scroll 參數）：

GET /index/_search?scroll=5m
{
  "query": { ... },
  "size": 100
}

?后續(xù)翻頁?：

POST /_search/scroll
{
  "scroll": "5m",
  "scroll_id": "xxx"
}

?手動清理?（重要?。?/p>

DELETE /_search/scroll
{ "scroll_id": "xxx" }

適用場景

• 數據導出、遷移、批量處理；
• 不要求實時性的后臺任務。

缺陷

• ?非實時?；
• 上下文長期駐留內存，易造成資源泄漏；
• ?ES 7+ 官方已不推薦用于分頁?。

2.3search_after：官方主推的深度分頁方案 

核心優(yōu)勢

• 基于 游標（cursor） 思想，無深度限制；
• 使用 Point In Time (PIT) 保證一致性；
• 資源占用遠低于 scroll；
• 支持 ?近實時查詢?。

關鍵要求

• ?必須指定排序字段?；
• ?**必須包含唯一決勝字段（tiebreaker）**?，如 _id，避免重復或跳過數據。

使用流程

創(chuàng)建 PIT（Point In Time）

POST /index/_pit?keep_alive=5m

→ 返回 pit_id

首次查詢

GET /_search
{
  "query": { "term": { "status": "active" } },
  "pit": { "id": "pit_id", "keep_alive": "1m" },
  "size": 20,
  "sort": [
    { "timestamp": "asc" },
    { "_id": "asc" }  // ← 唯一決勝字段！
  ]
}

后續(xù)翻頁（使用上一頁最后一條的排序值）

GET /_search
{
  "query": { "term": { "status": "active" } },
  "pit": { "id": "pit_id", "keep_alive": "5m" },
  "size": 20,
  "sort": [
    { "timestamp": "asc" },
    { "_id": "asc" }
  ],
  "search_after": [1678901234567, "doc_999"]  // ← 上一頁最后一條的值
}

釋放 PIT（可選但推薦）

DELETE /_pit
{ "id": "pit_id" }

適用場景

• APP ?下拉加載更多?（天然向后翻頁）；
• 電商商品列表、內容流（超 10000 條）；
• 對性能和一致性有要求的 C 端業(yè)務。

三、深度分頁的根本解決策略

策略 1：產品設計上規(guī)避深度分頁（最優(yōu)解）

最好的優(yōu)化，是不讓問題發(fā)生。

• ?PC 端?：隱藏“跳轉到第 N 頁”，僅保留“上一頁/下一頁”；
• ?限制最大頁數?：如淘寶、京東僅展示前 ?100 頁?；
• ?移動端?：采用 ?無限下拉加載?，天然適配 search_after。

策略 2：按業(yè)務場景精準選型

策略 3：用search_after實現高性能深度分頁

若必須深度分頁，請嚴格遵循以下最佳實踐：

1. ?排序字段必須含唯一決勝字段?（如 _id）；
2. ?PIT 過期時間合理設置?（如 1~5 分鐘），可在每次請求中續(xù)期；
3. ?單次 size 控制在 20~100?，平衡性能與請求次數；
4. ?查詢結束后主動刪除 PIT?，避免資源泄漏。

策略 4：集群級輔助優(yōu)化

• ?合理分片?：避免過多分片（建議 ≤ 節(jié)點數 × 2）；
• ?提升協調節(jié)點配置?：高內存 + 多核 CPU；
• ?關閉非必要排序?：若無需排序，可按 _doc（最快）；
• ?**使用路由（routing）**?：減少查詢涉及的分片數。

四、總結與核心建議

核心結論

1. from + size ≠ 深度分頁方案 —— 僅適用于 ≤10000 條的隨機翻頁；
2. scroll 已過時 —— 僅用于非實時全量處理；
3. search_after 是未來 —— ES 7.10+ 官方主推，性能與一致性兼得；
4. 產品設計 > 技術調優(yōu) —— 限制用戶行為是最高效解法。

落地建議

• ?產品側?：PC 限頁數，APP 用下拉；
• ?開發(fā)側?：封裝 search_after 工具類，統(tǒng)一處理 PIT 與游標；
• ?運維側?：監(jiān)控堆內存、GC 頻率，防止 OOM；
• ?架構側?：新項目?**直接放棄 scroll**?，全面擁抱 search_after。

到此這篇關于Elasticsearch深度分頁問題的解決方案詳解的文章就介紹到這了,更多相關Elasticsearch深度分頁內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論