MyBatis-Plus分页优化实战与性能提升指南

1. MyBatis-Plus分页优化实战指南

作为一名长期使用MyBatis-Plus的开发老兵，我深知分页查询是每个Java后端开发者都绕不开的话题。特别是在处理百万级数据时，一个不经意的分页操作就可能成为系统性能的"阿喀琉斯之踵"。今天我就来分享这些年积累的分页优化实战经验，从原理到实践，手把手教你打造高性能分页系统。

1.1 为什么分页优化如此重要？

在日常开发中，我们经常遇到这样的场景：订单管理需要分页展示、用户列表需要分页加载、报表数据需要分页查询。看似简单的分页功能，如果处理不当，轻则导致接口响应缓慢，重则引发数据库崩溃。

我曾在项目中遇到过这样一个真实案例：某电商平台的订单查询接口，在促销活动期间突然响应超时。排查后发现，开发人员直接使用了MyBatis-Plus的默认分页方式查询百万级订单表，导致每次查询都执行全表COUNT操作，数据库CPU直接飙到100%。

1.1.1 分页查询的四大性能杀手

1. COUNT查询性能瓶颈：特别是大表全表COUNT，在InnoDB引擎下需要全表扫描
2. LIMIT深度分页问题：LIMIT 1000000, 20这样的查询需要先扫描100万条记录
3. 数据传输开销：不必要的字段返回和重复数据传输
4. 内存压力：ORM层对象转换和结果集缓存占用大量JVM内存

2. MyBatis-Plus分页原理解析

2.1 分页插件工作机制

MyBatis-Plus的分页功能基于MyBatis的拦截器机制实现，核心类是PaginationInnerInterceptor。它的工作流程可以概括为：

1. 拦截待执行的SQL语句
2. 解析分页参数（当前页、每页条数）
3. 生成COUNT查询SQL并执行，获取总记录数
4. 修改原始SQL，添加LIMIT/OFFSET分页条件
5. 执行分页查询并封装结果

java复制// 典型的分页查询示例
Page<User> page = new Page<>(1, 10); // 当前页1，每页10条
userMapper.selectPage(page, Wrappers.<User>query().eq("status", 1));

2.2 分页参数封装

MyBatis-Plus使用Page对象封装分页参数和结果：

java复制public class Page<T> {
    private List<T> records;  // 当前页数据列表
    private long total;       // 总记录数
    private long size;        // 每页显示条数
    private long current;     // 当前页
    // 其他属性...
}

3. 分页性能优化实战

3.1 COUNT查询优化方案

方案一：禁用COUNT查询

当不需要总记录数时（如移动端上拉加载更多），可以禁用COUNT查询：

java复制Page<User> page = new Page<>(1, 10, false); // 第三个参数设为false表示不执行count查询

方案二：使用缓存COUNT结果

对于数据变化不频繁的表，可以缓存COUNT结果：

java复制@Cacheable(value = "userCountCache", key = "'total'")
public long getUserTotalCount() {
    return userMapper.selectCount(null);
}

方案三：优化COUNT语句

对于复杂查询，可以自定义COUNT SQL：

java复制@Select("SELECT COUNT(*) FROM user ${ew.customSqlSegment}")
Long selectUserCount(@Param(Constants.WRAPPER) Wrapper<User> wrapper);

3.2 深度分页优化方案

方案一：基于主键的分页

sql复制-- 传统方式（性能差）
SELECT * FROM user ORDER BY id LIMIT 1000000, 20;

-- 优化方式（性能好）
SELECT * FROM user WHERE id > 1000000 ORDER BY id LIMIT 20;

对应的MyBatis-Plus实现：

java复制userMapper.selectPage(
    new Page<>(1, 20),
    Wrappers.<User>query()
        .gt("id", lastMaxId)
        .orderByAsc("id")
);

方案二：使用子查询优化

sql复制SELECT * FROM user 
WHERE id IN (
    SELECT id FROM user ORDER BY create_time DESC LIMIT 1000000, 20
)

3.3 结果集优化

只查询必要字段

java复制userMapper.selectPage(
    new Page<>(1, 20),
    Wrappers.<User>query()
        .select("id", "name", "avatar")
        .eq("status", 1)
);

使用DTO投影

java复制@Select("SELECT id, name FROM user ${ew.customSqlSegment}")
List<UserDTO> selectUserDtoPage(@Param(Constants.WRAPPER) Wrapper<User> wrapper, Page<UserDTO> page);

4. 高级配置与最佳实践

4.1 分页插件自定义配置

java复制@Configuration
public class MybatisPlusConfig {
    
    @Bean
    public MybatisPlusInterceptor mybatisPlusInterceptor() {
        MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor();
        
        // 分页插件配置
        PaginationInnerInterceptor paginationInterceptor = new PaginationInnerInterceptor();
        paginationInterceptor.setMaxLimit(100L); // 单页最大记录数限制
        paginationInterceptor.setDbType(DbType.MYSQL); // 数据库类型
        paginationInterceptor.setOverflow(true); // 超出总页数后是否返回首页
        
        interceptor.addInnerInterceptor(paginationInterceptor);
        return interceptor;
    }
}

4.2 分页参数安全校验

java复制@GetMapping("/users")
public Result<Page<User>> listUsers(
    @RequestParam(defaultValue = "1") Integer current,
    @RequestParam(defaultValue = "10") Integer size) {
    
    // 参数校验
    if (current < 1) current = 1;
    if (size < 1 || size > 100) size = 10;
    
    return Result.success(userService.page(new Page<>(current, size)));
}

4.3 统一分页响应封装

java复制public class PageResult<T> {
    private Long current;
    private Long size;
    private Long total;
    private List<T> records;
    
    public static <T> PageResult<T> success(Page<T> page) {
        PageResult<T> result = new PageResult<>();
        result.setCurrent(page.getCurrent());
        result.setSize(page.getSize());
        result.setTotal(page.getTotal());
        result.setRecords(page.getRecords());
        return result;
    }
}

5. 实战中的坑与解决方案

5.1 多表联查分页问题

问题现象：在多表JOIN查询时，直接使用MyBatis-Plus分页会导致COUNT查询结果不准确。

解决方案：

1. 使用自定义SQL处理多表分页
2. 先查询主表ID分页，再通过IN查询关联数据

xml复制<!-- 先分页查询主表ID -->
<select id="selectUserIdsPage" resultType="long">
    SELECT id FROM user
    WHERE status = 1
    ORDER BY create_time DESC
    LIMIT #{offset}, #{size}
</select>

<!-- 再通过ID查询完整数据 -->
<select id="selectUsersByIds" resultType="User">
    SELECT * FROM user WHERE id IN
    <foreach collection="ids" item="id" open="(" separator="," close=")">
        #{id}
    </foreach>
</select>

5.2 大数据量导出问题

问题现象：需要导出大量数据时，传统分页方式效率极低。

解决方案：使用游标查询

java复制@Select("SELECT * FROM user ${ew.customSqlSegment}")
@Options(fetchSize = 1000, resultSetType = ResultSetType.FORWARD_ONLY)
@ResultType(User.class)
void selectUserForExport(@Param(Constants.WRAPPER) Wrapper<User> wrapper, ResultHandler<User> handler);

6. 性能对比测试

为了验证优化效果，我对不同分页方式进行了性能测试（测试环境：MySQL 8.0，100万条测试数据）：

从测试结果可以看出，优化后的分页方式性能提升显著。特别是在深度分页场景下，基于ID的分页比传统LIMIT方式快了近100倍。

7. 监控与调优建议

7.1 分页查询监控指标

1. 查询耗时：重点关注平均响应时间和长尾请求
2. COUNT查询占比：过高可能意味着不必要的COUNT操作
3. 分页深度分布：识别深度分页使用场景
4. 结果集大小：监控单次查询返回的数据量

7.2 调优建议

1. 为分页查询字段建立合适索引（特别是ORDER BY字段）
2. 定期分析慢查询日志，优化耗时长的分页SQL
3. 考虑使用读写分离，将分页查询放到从库执行
4. 对于超大数据集，考虑使用Elasticsearch等专业搜索引擎

在实际项目中，我通常会为分页接口添加如下监控：

java复制@Aspect
@Component
@Slf4j
public class PageQueryMonitorAspect {
    
    @Around("execution(* com..mapper.*Mapper.selectPage(..))")
    public Object monitorPageQuery(ProceedingJoinPoint joinPoint) throws Throwable {
        long start = System.currentTimeMillis();
        Object result = joinPoint.proceed();
        
        if (result instanceof Page) {
            Page<?> page = (Page<?>) result;
            long cost = System.currentTimeMillis() - start;
            
            Metrics.timer("page.query.time")
                   .tag("table", getTableName(joinPoint))
                   .record(cost, TimeUnit.MILLISECONDS);
            
            if (cost > 1000) {
                log.warn("Slow page query detected: {}ms, params: {}", cost, joinPoint.getArgs());
            }
        }
        
        return result;
    }
}

8. 未来演进方向

随着业务发展，分页方案也需要不断演进。以下是我总结的几个发展方向：

1. 分页缓存策略：实现智能化的分页结果缓存，特别是对于静态数据
2. 预计算分页：对于复杂分析查询，提前计算分页结果
3. 分布式分页：在分库分表环境下实现高效分页
4. 前端协同优化：与前端配合实现无限滚动等现代分页交互

在最近的项目中，我们尝试了将热点数据的分页结果预计算并存储到Redis中，使得95%的分页查询都能在5ms内返回，大大提升了用户体验。