【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

小结

    注意细节，每天进步一点点 ！