西陆强军号1. 项目背景与问题定义
最近在重构公司日志分析平台时，遇到了一个典型的ElasticSearch深分页性能问题。当用户需要查询第1000页之后的数据时，系统响应时间从正常的200ms飙升到8秒以上，甚至频繁触发超时报警。这种场景在运营后台、审计日志查询等业务中非常常见。
传统解决方案是使用from+size分页，但ES官方文档明确指出：深度分页的成本与from+size值成正比。例如from=10000,size=10时，ES需要在每个分片上先查询10010条结果，再在协调节点合并排序。当页数较深时，这会导致：
- 内存消耗指数级增长（需要缓存海量临时数据）
- 网络带宽浪费（节点间传输无用数据）
- CPU计算冗余（排序大量最终会被丢弃的记录）
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术方案选型
2.1 竞品方案对比
| 方案 | 原理 | 优点 | 缺点 |
|---|---|---|---|
| Scroll API | 维护游标上下文 | 适合大批量导出 | 占用服务端资源，实时性差 |
| from+size | 简单分页 | 实现简单 | 深度分页性能灾难 |
| Search After | 使用上一页最后记录排序值 | 性能最优，实时查询 | 需要保证排序字段唯一性 |
| 业务层缓存 | 缓存前N页结果 | 减轻ES压力 | 数据一致性难保证 |
2.2 Search After核心原理
Search After的工作机制类似于书签翻页：
- 首次查询指定sort字段（必须包含唯一键如_id）
- 获取最后一条记录的sort值数组
- 下次查询将该数组作为search_after参数传入
- ES直接在对应位置继续查询
java复制// 示例查询构造
SearchRequest request = new SearchRequest("logs");
SearchSourceBuilder sourceBuilder = new SearchSourceBuilder()
.query(QueryBuilders.matchAllQuery())
.sort(SortBuilders.fieldSort("timestamp").order(SortOrder.ASC))
.sort(SortBuilders.fieldSort("_id").order(SortOrder.ASC)) // 确保唯一性
.size(10);
if (lastSortValues != null) {
sourceBuilder.searchAfter(lastSortV