Elasticsearch 作为分布式全文检索引擎，是项目中日志检索、订单查询、商品搜索、数据统计、后台列表分页的核心组件，几乎所有中大型项目都在使用。
日常开发中，90%的开发者习惯直接使用 from+size 实现分页查询，用法简单、适配常规列表需求，开发效率极高。
但线上一直存在一个极其隐蔽、破坏力极强的故障：浅分页完全正常，深分页直接崩盘。
我之前线上遇到过一次严重线上事故：运营后台数据导出、批量翻页查询功能，前十页数据正常无异常，一旦翻到50页、100页之后，接口直接大面积超时、ES查询报错、部分数据缺失，严重影响数据统计和业务对账。
初期排查毫无头绪，索引分片正常、集群状态健康、无节点宕机、无日志报错，唯独深分页查询直接失效。最终深挖ES底层分片检索原理，才定位到根因：from+size 存在天生的深分页缺陷，完全不适合大数据量、大页码查询。
很多中小型项目长期裸奔使用默认分页，平时小数据量无感知，一旦数据累积到万级、十万级，立刻爆发线上故障。
今天结合真实生产复盘，彻底讲透ES深分页崩溃的底层原理、高频踩坑场景、三种分页方案的优劣对比，给出不同业务场景的根治解决方案。
一、线上故障现象：浅页正常，深页全面崩溃
本次生产故障核心表现，极具迷惑性：
1、前端查询前1-10页数据，响应速度极快，数据完整无错乱；
2、页码超过50页、100页后，接口响应时间从几十毫秒飙升至数秒；
3、页码持续增大，直接触发ES查询超时、连接中断、接口报错；
4、部分深分页查询成功返回，但存在数据重复、数据缺失、排序错乱问题；
5、ES集群CPU、内存无明显告警，集群状态完全正常。
最让人困惑的是，故障只出现在大页码场景，日常用户浅分页访问完全正常，测试环境无法复现，只有线上大数据量才会暴露问题。
二、底层核心原理：为什么from+size不能深分页？
很多开发者只懂用法，不懂ES分布式检索底层逻辑，这是踩坑的根本原因。
ES是分布式分片架构，一个索引会分为多个分片存储在不同节点。
当我们执行 from=1000、size=10 这种深分页查询时，ES的执行逻辑如下：
1、协调节点向所有分片发送查询请求；
2、每个分片各自查询前 1010 条数据（from+size）；
3、所有分片的数据汇总到协调节点；
4、协调节点全局排序、去重、截取第1000-1010条数据返回；
5、丢弃前面1000条无效数据。
致命问题就在这里：页码越深，需要查询、汇总、排序、丢弃的数据量越大。
当from值达到上万、十万级别，协调节点需要汇总海量数据，占用极大的CPU、内存、IO资源，极易触发查询超时、内存溢出、GC卡顿，最终导致接口崩溃。
同时ES官方有默认限制：index.max_result_window 默认1000，超过该值直接报错拒绝查询。
三、人为踩坑：绝大多数项目的错误优化方式
遇到深分页报错，90%开发者的第一解决方式：直接修改ES参数，调大 max_result_window 数值。
这是极度危险的治标不治本的操作。
单纯放大阈值，只是让ES允许更深的分页查询，并没有解决底层海量数据汇总、排序、丢弃的性能问题。短期看似恢复正常，长期会导致：
1、ES集群CPU持续居高不下；
2、大页码查询频繁超时，拖垮集群整体性能；
3、协调节点内存溢出，引发节点重启；
4、高并发场景下整条检索服务雪崩。
所以ES官方明确禁止使用 from+size 做大数据量深分页，该方式只适合后台简单浅列表场景。
四、三种ES分页方案对比（生产选型核心依据）
1、from+size 分页（小数据浅分页专用）
优点：代码简单、适配通用、无需额外字段；
缺点：深分页性能爆炸、数据量大必超时、有最大窗口限制；
适用场景：用户端列表、后台普通分页、页码≤10页的短列表查询。
2、Scroll 滚动分页（海量数据一次性导出专用）
原理：生成快照游标，基于游标持续拉取数据，无需全局排序汇总；
优点：支持十万、百万级海量数据查询，性能稳定；
缺点：游标有过期时间、不支持随机跳页、占用快照资源；
适用场景：数据批量导出、全量数据同步、日志批量拉取、离线统计。
3、Search_After 分页（生产深分页最优解）
原理：基于上一页最后一条数据的排序值，向后增量查询，无海量数据汇总；
优点：性能极高、无页码限制、不占用大量资源、支持实时数据；
缺点：需要唯一排序字段、不支持随机跳页，只适合顺序翻页；
适用场景：运营后台深分页、大数据列表连续翻页、实时数据查询。
五、生产级故障根治：场景化最优解决方案
1、普通用户列表、浅分页场景
继续保留 from+size，同时严格限制最大查询页码，前端禁止用户翻页过深，超过阈值提示导出查看，从业务层规避深分页风险。
2、后台运营深分页、连续翻页场景
全面替换为 search_after 分页，设计唯一排序字段（时间+ID），保证数据有序不重复、不缺失，彻底解决深分页性能崩溃问题。
3、数据导出、全量同步场景
使用 scroll 滚动查询，设置合理快照过期时间，批量分片拉取数据，避免单次查询数据量过大导致超时。
六、生产高频踩坑总结
1、绝对不要通过调大 max_result_window 解决深分页报错，属于饮鸩止渴；
2、from+size 仅限浅分页，严禁用于大数据量、高页码查询；
3、search_after 必须搭配唯一排序字段，否则会出现数据错乱、重复遗漏；
4、scroll 游标需及时清理，避免长期占用ES快照资源；
5、不同业务场景必须匹配对应分页方案，一套代码走到底必然埋坑。
七、总结
ES深分页故障，是典型的开发只懂用法、不懂底层原理导致的线上疑难问题。
from+size 简单好用，但存在天生的分布式分页缺陷，随着业务数据量增长，必然爆发性能危机。
真正的生产级ES架构，一定是场景化选型分页方案：浅分页用from+size、连续深分页用search_after、海量导出用scroll。三层方案各司其职，彻底根治分页超时、数据缺失、集群性能雪崩问题。
规范ES分页使用，是保障检索服务长期稳定、低延迟、高可用的核心关键。
