MyBatis-Plus分页查询中ResultType缺失导致结果映射失效问题解析

问题现象

在使用MyBatis-Plus进行分页查询时，开发者可能会遇到一个隐蔽的问题：当XML映射文件中未明确指定resultType属性时，查询返回的Page对象中records列表的所有元素均为null，尽管total字段和records列表的size显示正常。这个问题的特殊性在于：

1. 仅在使用分页查询时出现
2. 不抛出任何异常或警告
3. 非分页查询下自动映射仍能正常工作
4. 添加resultType后问题立即解决

问题本质

这个问题实际上涉及MyBatis和MyBatis-Plus的多个核心机制：

1. MyBatis的结果映射机制：MyBatis在无resultType/resultMap时尝试自动映射，但分页场景下存在特殊处理
2. MyBatis-Plus的分页实现：MyBatis-Plus的分页插件对结果集进行了额外处理
3. 空行处理策略：MyBatis对空结果行的默认处理方式

在分页查询中，MyBatis-Plus的分页拦截器会修改原始SQL并处理结果集。当缺少resultType时，MyBatis无法确定如何映射结果行，而默认配置下(return-instance-for-empty-row=false)，MyBatis会返回null而不是创建空实例。

解决方案

推荐方案

1. 显式指定resultType：这是最规范的做法，明确指定返回类型

<select id="selectByNotDeletedAndUserId" resultType="org.example.entity.Course">
    SELECT * FROM course WHERE deleted = 0 AND user_id = #{userId}
</select>

2. 配置return-instance-for-empty-row：修改MyBatis配置

mybatis-plus:
    configuration:
        return-instance-for-empty-row: true

方案比较

方案	优点	缺点	适用场景
指定resultType	明确、规范、可读性好	需要额外编写	推荐长期项目使用
修改配置	全局生效、无需修改现有SQL	可能掩盖其他映射问题	快速修复、遗留系统

深入理解

MyBatis自动映射机制

MyBatis在没有明确resultType/resultMap时，会尝试自动映射结果集到返回类型。这种机制依赖于：

1. 方法返回类型信息
2. 数据库列名与Java属性的对应关系

但在分页查询中，MyBatis-Plus的PageInterceptor会改变这一行为，因为它需要处理分页信息。

MyBatis-Plus分页实现

MyBatis-Plus的分页插件工作流程：

1. 拦截Executor.query方法
2. 修改原始SQL添加分页语句
3. 执行count查询获取总数
4. 执行分页查询获取数据
5. 构造Page对象返回

在这个过程中，如果缺少resultType，插件可能无法正确推断结果类型。

最佳实践

1. 始终指定resultType/resultMap：即使是简单查询
2. 统一命名规范：保持数据库列名与Java属性名一致
3. 启用SQL日志：方便调试映射问题
4. 考虑使用注解方式：避免XML配置遗漏

@Select("SELECT * FROM course WHERE deleted = 0 AND user_id = #{userId}")
Page<Course> selectByNotDeletedAndUserId(Page<Course> page, Integer userId);

总结

MyBatis-Plus分页查询中的这个映射问题看似简单，实则涉及框架的多个核心机制。作为开发者，理解这些底层原理不仅能快速解决问题，还能避免类似陷阱。显式指定resultType是最稳妥的做法，既能保证功能正常，也提高了代码的可维护性。