若依框架里MyBatis分页失效？别在Service层循环查数据库了！
若依框架中MyBatis分页失效的深度解析与解决方案
业务场景中的分页困境
最近在若依(RuoYi)框架项目中遇到一个棘手问题：系统需要根据不同部门权限展示数据列表，但分页功能突然失效。具体表现为前端明明请求了每页10条数据，返回结果却包含所有符合条件的数据记录。经过排查，发现问题出在Service层的循环查询逻辑上。
这种情况在权限管理系统开发中相当常见。比如一个HR系统需要根据登录用户的部门权限展示员工信息：管理员可以看到全公司数据，普通用户只能查看本部门数据，而部门主管可能需要查看多个关联部门的数据。当处理多部门数据查询时，很多开发者会不假思索地采用循环查询的方式拼接结果集，这正是导致分页失效的罪魁祸首。
分页失效的根本原因
要理解这个问题，我们需要深入MyBatis分页插件（如PageHelper）的工作原理。分页插件的核心机制是通过拦截器对SQL进行动态改写，添加LIMIT子句实现分页。但这个拦截过程有几个关键特性：
- 单次拦截原则：PageHelper只会对
startPage()方法后执行的第一个查询语句进行拦截和分页处理 - 线程绑定机制：分页参数通过ThreadLocal存储，执行完第一个查询后会自动清除
- 结果集后处理不可行：插件无法对内存中合并的多个查询结果进行分页
在原始的问题代码中，Service层通过循环多次调用selectList2方法，每次查询一个部门的数据然后合并。这种写法存在两个致命缺陷：
// 问题代码示例 for (String deptId : deptIds) { List<SysTest> sysTestList2 = sysTestMapper.selectList2(name, deptId); sysTestList.addAll(sysTestList2); // 内存合并结果集 }首先，只有第一次循环的查询会被PageHelper拦截分页，后续查询都会绕过拦截直接获取全量数据。其次，即使所有查询都被分页，内存合并后的结果集大小也会超出单页限制，导致分页形同虚设。
解决方案：SQL层统一分页
正确的解决思路是将多部门查询逻辑下沉到SQL层，通过一次查询获取所有需要的数据。MyBatis的动态SQL功能可以完美支持这种需求：
1. Mapper接口改造
将原来的单个deptId参数改为接收deptIds集合：
List<SysTest> selectList( @Param("name") String name, @Param("deptIds") List<String> deptIds );2. XML映射文件优化
使用<foreach>标签实现IN查询：
<select id="selectList" resultType="SysTest"> SELECT * FROM sys_test LEFT JOIN sys_sq ON sys_test.id = sys_sq.rc_id WHERE sys_sq.status = 3 <if test="name != null and name != ''"> AND sys_rc.name LIKE CONCAT('%', #{name}, '%') </if> <if test="deptIds != null and deptIds.size() > 0"> AND sys_sq.dept_id IN <foreach collection="deptIds" item="deptId" open="(" separator="," close=")"> #{deptId} </foreach> </if> </select>3. Service层简化
移除循环查询逻辑，直接传递部门ID集合：
public List<SysTest> selectList(String name) { SysUser user = SecurityUtils.getLoginUser().getUser(); if (user.getDeptId() == null) { return sysTestMapper.selectList(name, null); } else { List<String> deptIds = Arrays.asList(user.getDeptId2().split(",")); return sysTestMapper.selectList(name, deptIds); } }性能对比与最佳实践
为了更直观地展示优化效果，我们对比两种方案的性能差异：
| 指标 | 循环查询方案 | IN查询方案 |
|---|---|---|
| 数据库查询次数 | N次(N=部门数) | 1次 |
| 网络IO开销 | 高 | 低 |
| 内存消耗 | 高 | 低 |
| 分页准确性 | 失效 | 正常 |
| 代码可维护性 | 差 | 好 |
在实际项目中，还有一些值得注意的最佳实践：
- IN查询的性能考量：当部门ID数量很大时(如超过1000)，应考虑改用JOIN或临时表方案
- 分页参数的传递：确保
startPage()在Controller调用，不要在Service层使用 - 统一异常处理：对分页参数进行校验，避免非法值导致性能问题
提示：在若依框架中，可以直接使用
TableDataInfo和getDataTable()方法构建分页响应，保持与框架风格一致。
深入理解PageHelper原理
要彻底避免这类问题，有必要了解PageHelper的内部机制。其核心拦截逻辑如下：
- 拦截点：基于MyBatis的Interceptor接口，拦截
Executor的query方法 - 参数解析：从ThreadLocal获取
Page对象，包含pageNum和pageSize - SQL改写：根据方言(Dialect)在原SQL上添加分页语句
- MySQL:
LIMIT offset, pageSize - Oracle: 使用ROWNUM嵌套查询
- MySQL:
- 总数查询：自动执行COUNT查询获取总记录数
- 资源清理：执行完成后清除ThreadLocal中的分页参数
这种设计决定了它无法对内存中的集合操作进行分页，必须在数据库层面完成分页逻辑。这也是为什么我们应该尽量避免在Service层做数据聚合操作。
复杂场景的扩展方案
对于更复杂的多表关联分页查询，还有几种进阶解决方案：
1. 子查询分页
SELECT * FROM ( SELECT t.*, ROW_NUMBER() OVER(ORDER BY create_time DESC) AS rn FROM sys_test t WHERE t.dept_id IN (1,2,3) ) WHERE rn BETWEEN 11 AND 202. 游标分页
// 使用lastId作为游标 List<SysTest> selectPage( @Param("name") String name, @Param("deptIds") List<String> deptIds, @Param("lastId") Long lastId, @Param("pageSize") int pageSize );3. 存储过程分页
对于超大规模数据，可以考虑使用数据库存储过程封装分页逻辑，减少网络传输开销。
常见误区与排查技巧
在实际开发中，还有一些容易导致分页问题的错误用法：
错误的调用顺序：
List<User> list = mapper.selectAll(); // 先查询 PageHelper.startPage(1, 10); // 后分页 - 无效!线程污染问题：
new Thread(() -> { PageHelper.startPage(1, 10); // 新线程无法继承ThreadLocal mapper.selectAll(); }).start();PageHelper版本差异：
- 5.0.x版本需要配合PageHelper.offsetPage使用
- 5.1.x后推荐使用PageHelper.startPage
当分页出现问题时，可以通过以下步骤快速定位：
- 检查SQL日志，确认是否生成了LIMIT子句
- 确认PageHelper.startPage()在正确位置调用
- 检查是否有循环查询或内存过滤操作
- 验证MyBatis拦截器配置是否正确加载
在若依框架中，分页配置通常位于application.yml：
pagehelper: helper-dialect: mysql reasonable: true support-methods-arguments: true工程实践建议
为了构建健壮的分页功能，推荐采用以下工程实践：
统一分页封装：
public class PageUtils { public static void startPage() { PageDomain pageDomain = TableSupport.buildPageRequest(); PageHelper.startPage(pageDomain.getPageNum(), pageDomain.getPageSize()); } }分页参数校验：
public void validatePageParams(int pageNum, int pageSize) { if (pageNum < 1 || pageSize < 1 || pageSize > MAX_PAGE_SIZE) { throw new IllegalArgumentException("分页参数不合法"); } }DTO设计：
@Data public class PageResult<T> { private List<T> rows; private long total; private int pageNum; private int pageSize; }AOP统一处理：
@Around("execution(* *..controller..*.*(..))") public Object doAround(ProceedingJoinPoint pjp) throws Throwable { PageUtils.startPage(); Object result = pjp.proceed(); return TableSupport.getDataTable(result); }
这些实践能够使分页逻辑更加清晰、统一，减少出错概率。特别是在若依这类快速开发框架中，良好的分页设计可以显著提升开发效率。