PageHelperPageHelper分页失效
Posted 奔跑的大白啊
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了PageHelperPageHelper分页失效相关的知识,希望对你有一定的参考价值。
前言 |
各位老铁们,我又来啦~ 在经过了一个国庆假期加班的项目紧张时期后,终于终于也克服了自己的懒筋,来写点文字吧!
国庆节之前在日常测试一个分页查询接口,库里一种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
小结 |
注意细节,每天进步一点点 !
以上是关于PageHelperPageHelper分页失效的主要内容,如果未能解决你的问题,请参考以下文章