Pagehelper的reasonable配置引起分页失效问题
发布网友
发布时间：2024-10-24 04:03
共1个回答
热心网友
时间：2024-11-06 16:30
某日，一个意外的接口请求激发了我对分页机制的好奇心。前端请求一个列表，却遇到了两个出乎意料的问题。第一，get请求包含pageNum和pageSize参数，数据库执行的是常规的查询语句，并未使用limit，也未配置分页相关的bean或mybatis，却能实现分页效果。第二，请求时传入分页参数，结果却总是返回第一页的数据。
为了揭开这个谜团，我开始了细致的源码分析。通过一系列的排查，最终找到了问题的根源。原来，引入的pagehelper插件在SpringBoot中自动配置了分页功能，无需额外的mybatis配置和PageHelper.startPage(pageNum, pageSize)的调用。这得益于SpringBoot的自动装配特性。在使用pagehelper时，通常需要在执行SQL前手动调用startPage方法，但在这个案例中，这个步骤被自动完成了。问题的关键在于，page对象在初始化时就已经赋值，而这个值是由@EnablePage注解在全局范围内设置的，这个注解会在项目启动时自动执行。这样，即使在Controller层使用了pageNum和pageSize参数，页面也会返回第一页的数据。
接着，第二个问题浮现。当请求的页码超出实际存在的页数时，页面总是返回第一页的数据。深入分析后发现，问题出在分页插件的中，这个在计算总数时，对pageNum进行了重新计算，导致最终返回的是第一页的数据。这个行为是为了防止分页不合理的情况，如页码过大或为负数，会默认返回第一页。然而，这个机制默认为合理化计算，即reasonable属性为true，导致了问题的出现。解决方法是将reasonable属性设置为false，或者在调用PageHelper.startPage时传入false作为参数，以避免自动计算。另外，不配置合理化参数也是一个选择，因为其默认值为false。
通过这次深入的源码分析，我不仅解决了眼前的两个问题，还对PageHelper和mybatis的分页机制有了更深入的理解。同时，我也意识到分页合理化参数的使用需要谨慎考虑，因为它可能会导致某些情况下的死循环问题，尤其是在批量导出数据时，若数据量大，一次性全读取可能会陷入死循环。因此，个人建议在实际应用中，使用默认配置或明确设置为false，以避免潜在的逻辑问题。
