高性能分页查询优化方案与实践

1. 分页查询的本质与业务价值

分页查询是业务系统中最基础却最容易被低估的技术模块。在电商平台工作时，我们曾因分页实现不当导致促销活动页加载延迟高达8秒——当用户翻到第50页时，数据库实际扫描了前49页的全部数据。合理的分页实现能将同样场景的响应时间控制在200ms内。

分页的核心矛盾在于：用户只需要看到当前页的20条数据，但数据库需要知道从哪里开始截取这20条。传统方案（如MySQL的LIMIT）在深度分页时会产生严重的性能问题。假设每页20条数据，当用户请求第1000页时，数据库需要先扫描19980条记录才能定位到第1000页的起始位置。

2. 基础实现方案与性能陷阱

2.1 原生SQL分页实现

MySQL标准分页语法看似简单：

sql复制SELECT * FROM products 
ORDER BY create_time DESC 
LIMIT 200, 20;  -- 第11页(200=(11-1)*20)

但在千万级数据表中，这个查询可能产生灾难性后果。我曾用EXPLAIN分析过一个真实案例：

• 没有合适索引时，查询需要扫描全表
• 即使有索引，深度分页时优化器可能放弃索引
• 典型执行计划显示"Using filesort"和"Using temporary"

关键发现：当offset值超过10000时，响应时间呈指数级增长。在500万数据的商品表中，第500页(offset 10000)查询耗时从第1页的5ms暴增到1200ms。

2.2 MyBatis分页插件原理

主流方案如PageHelper通过拦截器改写SQL。其核心流程：

1. 拦截Executor.query()方法
2. 解析ThreadLocal存储的Page对象
3. 改写原始SQL添加LIMIT子句
4. 执行count查询获取总数

但需要注意：

• 务必在PageHelper.startPage()后立即执行查询
• 多个分页查询需要嵌套使用PageHelper
• 分布式环境下需要特殊处理ThreadLocal

3. 高性能分页方案实战

3.1 游标分页实现

在社交feed流场景中，我们采用基于create_time的游标分页：

java复制public PageResult<Product> listProducts(Long lastId, int pageSize) {
    List<Product> products = productMapper.selectAfterId(
        lastId, 
        pageSize
    );
    Long nextLastId = products.isEmpty() ? 
        null : products.get(products.size()-1).getId();
    return new PageResult(products, nextLastId);
}

配套的Mapper XML：

xml复制<select id="selectAfterId" resultMap="productMap">
    SELECT * FROM products
    WHERE id > #{lastId}
    ORDER BY id ASC
    LIMIT #{pageSize}
</select>

优势对比：

3.2 覆盖索引优化

对于复杂查询，我们创建专用索引：

sql复制ALTER TABLE orders 
ADD INDEX idx_status_creator_time (status, creator_id, create_time);

查询改写为：

java复制public interface OrderMapper {
    @Select("SELECT id FROM orders WHERE status=#{status} " +
            "AND creator_id=#{userId} ORDER BY create_time DESC " +
            "LIMIT #{offset}, #{pageSize}")
    List<Long> listOrderIdsByPage(PageParam param);
    
    @Select("<script>SELECT * FROM orders WHERE id IN " +
            "<foreach item='id' collection='ids' open='(' separator=',' close=')'>" +
            "#{id}</foreach></script>")
    List<Order> batchGetOrders(@Param("ids") List<Long> ids);
}

这种"二次查询"方案虽然增加了一次数据库交互，但总体性能提升显著：

1. 第一次查询只扫描索引列
2. 主键查询可以利用缓冲池
3. 避免了大数据量的排序操作

4. 复杂场景下的分页方案

4.1 多表关联分页

在订单-商品关联查询时，传统JOIN分页会导致：

• 结果集膨胀（一个订单对应多个商品）
• 分页计数不准确

我们的解决方案：

java复制// 先分页查询订单ID
Page<Long> orderIds = orderMapper.selectOrderIdsByPage(pageParam);

// 再批量查询关联数据
List<OrderDTO> orders = orderIds.stream()
    .map(id -> {
        Order order = orderMapper.selectById(id);
        List<Product> products = productMapper.selectByOrderId(id);
        return new OrderDTO(order, products);
    })
    .collect(Collectors.toList());

4.2 Elasticsearch分页

对于全文检索场景，ES分页有特殊限制：

• 默认最多返回10000条结果
• 深度分页使用search_after而非from/size

Java实现示例：

java复制SearchRequest request = new SearchRequest("products");
SearchSourceBuilder sourceBuilder = new SearchSourceBuilder();
sourceBuilder.query(QueryBuilders.matchQuery("name", "手机"));
sourceBuilder.size(20);

// 使用search_after参数
if (lastSortValues != null) {
    sourceBuilder.searchAfter(lastSortValues);
}

request.source(sourceBuilder);
SearchResponse response = client.search(request, RequestOptions.DEFAULT);

// 记录最后一条的sort值用于下一页
Object[] lastSort = response.getHits()
    .getHits()[response.getHits().getHits().length - 1]
    .getSortValues();

5. 分页结果封装规范

推荐统一响应结构：

java复制public class PageResult<T> {
    private Integer pageNum;
    private Integer pageSize;
    private Integer totalPage;
    private Long total;
    private List<T> data;
    private Object extra; // 扩展字段
    
    public static <T> PageResult<T> success(PageInfo<T> pageInfo) {
        PageResult<T> result = new PageResult<>();
        result.setPageNum(pageInfo.getPageNum());
        result.setPageSize(pageInfo.getPageSize());
        result.setTotal(pageInfo.getTotal());
        result.setTotalPage(pageInfo.getPages());
        result.setData(pageInfo.getList());
        return result;
    }
}

Controller层统一处理：

java复制@GetMapping("/products")
public ResponseEntity<PageResult<Product>> listProducts(
    @RequestParam(defaultValue = "1") Integer pageNum,
    @RequestParam(defaultValue = "20") Integer pageSize) {
    
    PageHelper.startPage(pageNum, pageSize);
    List<Product> products = productService.listAll();
    PageInfo<Product> pageInfo = new PageInfo<>(products);
    
    return ResponseEntity.ok(PageResult.success(pageInfo));
}

6. 性能监控与优化建议

我们通过APM工具发现的分页性能瓶颈TOP3：

1. 未使用索引的排序字段（占问题总量的47%）
2. 不必要的COUNT查询（32%）
3. 大字段查询（21%）

优化检查清单：

• [ ] 所有ORDER BY字段必须有索引
• [ ] 超过100万的表考虑放弃精确COUNT
• [ ] 禁用SELECT *，明确列出字段
• [ ] 深度分页场景采用游标方案
• [ ] 分页大小不超过100条

在商品搜索服务中，通过以下优化将第100页查询从2100ms降到85ms：

1. 使用id作为游标替代页码
2. 建立(status, category_id, score)复合索引
3. 禁用列表查询的商品详情字段
4. 采用异步COUNT策略