分页插件pagehelper统计的数量不对加where筛选

2024年2月3日发(作者：)

分页插件pagehelper统计的数量不对加where筛选

项目一直使用的是PageHelper实现分页功能，项目前期数据量较少一直没有什么问题。随着业务扩增，数据库扩增PageHelper出现了明显的性能问题。几十万甚至上百万的单表数据查询性能缓慢，需要几秒乃至十几秒的查询时间。故此特地研究了一下PageHelper源码，查找PageHelper分页的实现方式。

一段较为简单的查询，跟随debug开始源码探寻之旅。

主要保存由前端传入的pageNum(页数)、pageSize(每页显示数量)和count(是否进行count(0)查询)信息。

开始执行真正的select语句

进入MapperProxy类执行invoke方法获取到方法名称及参数值

接着是MapperMethod方法执行execute语句，判断是增、删、改、查。判断返回值是多个，进入executeForMany方法

这个方法开始调用SqlSessionTemplate、DefaultSqlSession等类获取到文件的SQL语句

开始进入PageHelper的真正实现，Plugin通过实现InvocationHandler进行动态代理获取到相关信息

PageInterceptor实现Mybatis的Interceptor接口，进行拦截

转到ExecutorUtil抽象类的pageQuery方法

在抽象类AbstractHelperDialect的getPageSql获取到对应的Page对象

进入到MySqlDialect类的getPageSql方法进行SQL封装，根据page对象信息增加Limit。分页的信息就是这么拼装起来的

将最后拼装好的SQL返回给DefaultSqlSession执行查询并返回

至此整个查询过程完成，原来PageHelper的分页功能是通过Limit拼接SQL实现的。查询效率低的问题也找出来了，那么应该如何解决。

首先分析SQL语句，limit在数据量少或者页数比较靠前的时候查询效率是比较高的。(单表数据量百万进行测试)

select*fromuserwhereage=10limit1,10;结果显示0.43s

当where条件后的结果集较大并且页数达到一个量级整个SQL的查询效率就十分低下(哪怕where的条件加上了索引也不行)。

select*fromuserwhereage=10limit100000,10;结果显示4.73s

SELECTa.*FROMUSERa

INNERJOIN

(SELECTidFROMUSERWHEREage=10LIMIT100000,10)b

=;

结果0.53s

完美解决了查询效率问题！！！其中需要对where条件增加索引，id因为是主键自带索引。select返回减少回表可以提升查询性能,所以采用查询主键字段后进行关联大幅度提升了查询效率。