引言

"每次翻页都要卡10秒，这系统没法用了！" 这是某电商平台工程师小王在凌晨三点发出的哀嚎。面对每天千万级的商品搜索请求，他们使用的Elasticsearch分页方案在高并发场景下频频崩溃。这个场景折射出大数据时代分页性能优化的必要性——当数据量突破千万级时，传统分页方法就像用吸管喝珍珠奶茶，既喝不到料又容易呛着。

一、from+size的致命缺陷

Elasticsearch默认的分页方式如同实体书翻页：

from elasticsearch import Elasticsearch

es = Elasticsearch()

# 获取第100页数据（每页10条）
response = es.search(
    index="products",
    body={
        "query": {"match_all": {}},
        "from": 990,  # 页码计算：(100-1)*10
        "size": 10
    }
)

这个看似简单的操作背后隐藏着巨大隐患：ES需要计算前990条数据的排序结果才能返回第100页数据。当数据量达到百万级时，就像要求快递员必须记住所有包裹的位置才能取出第1000个包裹。

二、性能优化三板斧

2.1 Scroll API：批量处理的救星

适合数据导出场景，原理如同书签式阅读：

# 初始化滚动查询
response = es.search(
    index="products",
    scroll='2m',  # 滚动保持时间
    size=100,
    body={"query": {"match_all": {}}}
)

scroll_id = response['_scroll_id']

# 持续获取后续批次
while len(response['hits']['hits']):
    response = es.scroll(
        scroll_id=scroll_id,
        scroll='2m'
    )
    # 处理本批数据...

技术特点：

  • 适合离线处理（如报表生成）
  • 保持搜索上下文需要内存开销
  • 滚动ID存在时效性（类似图书馆闭馆时间）
2.2 Search After：实时分页的利器

基于排序值的接力查询，如同接力赛跑：

# 首次查询
first_page = es.search(
    index="products",
    body={
        "query": {"range": {"price": {"gte": 100}}},
        "sort": [
            {"create_time": "asc"},  # 主排序字段
            {"_id": "asc"}  # 辅助排序确保唯一性
        ],
        "size": 10
    }
)

# 后续查询使用最后一条记录的排序值
last_hit = first_page['hits']['hits'][-1]
search_after = last_hit['sort']

next_page = es.search(
    index="products",
    body={
        "query": {"range": {"price": {"gte": 100}}},
        "sort": [
            {"create_time": "asc"},
            {"_id": "asc"}
        ],
        "search_after": search_after,
        "size": 10
    }
)

关键技术点：

  • 必须保持稳定排序（推荐主键参与排序）
  • 支持实时数据变更（新增数据不影响已有分页）
  • 查询复杂度与页码无关

三、深度优化策略

3.1 复合索引设计

在商品搜索场景中，通过预计算加速排序：

# 创建优化索引的示例
es.indices.create(
    index="products_v2",
    body={
        "mappings": {
            "properties": {
                "sales_rank": {  # 预计算的销售权重值
                    "type": "float",
                    "index": false  # 不单独建立索引
                },
                "hot_score": {   # 热度综合评分
                    "type": "rank_feature"  # 专门用于排序的特殊类型
                }
            }
        }
    }
)

这种设计：

  • 将多个排序因子预计算为单个字段
  • 使用rank_feature字段类型加速排序
  • 减少动态计算带来的性能损耗
3.2 搜索路由优化

对于分片数过多的集群：

# 指定路由参数减少涉及分片数
es.search(
    index="products",
    routing="user123",  # 按用户ID路由
    body={
        "query": {
            "term": {"user_id": "user123"}
        }
    }
)

优势：

  • 将相关数据集中在特定分片
  • 减少跨分片查询开销
  • 提升缓存命中率

四、技术选型指南

方案 适用场景 响应时间 内存消耗 实时性
from+size 小数据量分页 线性增长 高 实时
Scroll API 大数据量离线导出 固定 中 快照模式
Search After 大数据量实时分页 恒定 低 实时

五、避坑指南（注意事项）

  1. 排序稳定性陷阱：当两条记录的排序值相同时，必须添加唯一字段（如_id）作为第二排序条件
  2. 内存泄漏警报：Scroll查询必须及时清理 
    es.clear_scroll(scroll_id=scroll_id)
  3. 版本兼容性：Search After要求ES 5.0+，Scroll在7.x版本后推出新式滚动
  4. 深度分页限制：默认max_result_window为10000，修改需谨慎

六、总结与展望

经过三个月的优化实践，小王团队的搜索接口TP99从12秒降至200毫秒。这启示我们：在大数据分页场景下，抛弃传统分页思维，拥抱Search After等现代方案，配合智能路由和索引设计，才能实现质的飞跃。未来随着ES的持续演进，分页优化将呈现以下趋势：

  1. 向量检索与分页的结合
  2. 硬件加速排序的实现
  3. 自适应分页策略的智能化