PageHelper排查PageHelper分页失效问题

Posted 奔跑的大白啊

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了PageHelper排查PageHelper分页失效问题相关的知识,希望对你有一定的参考价值。

前言

    各位老铁们,我又来啦~ 在经过了一个国庆假期加班的项目紧张时期后,终于终于也克服了自己的懒筋,来写点文字吧!
     国庆节之前在日常测试一个分页查询接口,库里一种10条数据,一页10条,查询第1页,结果显示10条,这是正常的,但是当我随心所欲地改参数为查询第3页、第5页,每页记录数不变的情况下,结果还是显示一模一样的10条,啊~ 这~~,看起来神奇的存在!

pagehelper 分页查询失效

postman 分页查询测试

    我的库里一共10条数据,当查询第六页,每页显示两条记录时,按道理应该查询为空啊,但是竟然查出来数据了,此处隐约觉得是自己写的bug😌(后来一想有种侥幸心理:按照页面上方式普通用户应该看不出来这个问题)。

问题分析与解决

    前提:分页查询时page(pageNum)为3,pageSize为10;
    看控制台的sql执行语句,先来看正常的分页查询打印出来的分页查询:
    当我们传输page(pageNum)、pageSize两个参数时,拦截器会在原sql语句后面拼接上limit ?,? 两个参数分别为(pageNumber-1)*pageSize,pagesize

    再来看上面翻车的分页查询语句:好家伙,limit ?, 少给它拼接了一个参数呐!!!

    就去debug了PageHelper的代码,发现果然有猫腻:


    pages为查询的总页数,pageNum 为当前查询页数;
    当reasonable为true 并且记录的总页数> 查询页数时,查询页数会被更新为记录的总页数;
    所以,当我在传参时,满足pageNum * pageSize > pages 条件,pageNum 会被置为pages ,对应到postman测试时,库中满足条件的总记录数为10,当pageNum 为6 ,pageSize为2时,pages为10/2=5; 此时的pageNum>pages,所以pageNum = 5, 显示的是第5页的数据;当pageNum为3,pageSize为10时,pages为10/10=1; 此时的pageNum > pages,所以pageNum=1, 显示的是第1页的数据;

    reasonable 是pagehelper分页合理化的设置项,默认是false;
    当设置reasonable=true时,如果用户传入的页数已经大于了总页数,则会将用户传入的pageNum修改为总页数pages,默认查询最后一页的数据,当禁用此参数或者设置为false时,当用户传入的页数已经大于了总页数,会返回为空

    再来看我的配置文件,果然是它的锅(复制过来的时候瞎搞😠):

    当我把此配置项去掉后,再来看查询结果正常了:

    还可以在分页查询时指定此参数:
    调用startPage时传入reasonable参数 为false

小知识

    pagehelper的reasonable 默认为false,遇到查询页数大于总页数时,查询为空;当reasonable设置为true时,遇到查询页数大于总页数时,查询最后一页数据;

参考链接

https://www.cnblogs.com/lykbk/p/sdsdshjkhoh345345345345345.html
https://blog.csdn.net/shenchaohao12321/article/details/84201136

小结

    注意细节,每天进步一点点 !

以上是关于PageHelper排查PageHelper分页失效问题的主要内容,如果未能解决你的问题,请参考以下文章

MyBatis 使用PageHelper分页不起作用

pagehelper分页原理浅析

clickhouse pageHelper分页

分页插件PageHelper

并没有使用pagehelper进行分页查询,为啥还是调用了

pagehelper总条数最大7设置