光源资本1. 为什么Elasticsearch分页会成为性能杀手？
第一次接触Elasticsearch的开发者，往往会被其强大的全文检索能力所吸引，直到某天凌晨被报警短信吵醒——页面加载超时，而问题就出在那个看似无害的"下一页"按钮。我曾在电商平台处理过这样的事故：当用户翻到第50页商品列表时，API响应时间从200ms陡增至12秒，整个集群CPU飙升至90%。
Elasticsearch的分页机制与传统数据库有本质区别。当你执行from=10000, size=10的查询时，它不是在磁盘上跳过前99990条记录，而是需要在每个分片上先收集10010条结果（from+size），然后在协调节点合并排序。这意味着翻页越深，资源消耗呈指数级增长。
关键认知：深度分页的成本不是线性增长，而是O(n²)复杂度。请求第100页消耗的资源不是第10页的10倍，而是接近100倍。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 四种分页方案全链路压测对比
2.1 传统from+size方案
在8核32G的测试集群上，我们模拟不同分页深度的QPS表现：
| 页码范围 | 平均响应时间 | 集群CPU使用率 |
|---|---|---|
| 1-10页 | 23ms | 15% |
| 50-60页 | 217ms | 45% |
| 500-510页 | 4.2s | 83% |
| 5000+页 | >15s | 频繁GC |
问题本质在于：每次请求都要重新构建完整的排序队列。我曾通过修改index.max_result_window临时救火，但这只是把炸弹引爆时间推迟。
2.2 search_after方案实战
基于排序键的游标分页才是正解。假设商品列表按price,-sales排序：
json复制{
"size": 10,
"sort": [
{"price": "asc"},
{"sales": "desc"},
{"_id": "asc"} // 确保排序唯一性
],
"search_after": [299.00, 1500, "abc123"] /