MyBatisPlus数据映射问题解析与解决方案

1. 问题现象与背景分析

最近在项目Review时发现一个诡异现象：通过MyBatisPlus查询出的实体对象字段值与数据库表中的实际记录不一致。例如数据库里status字段明明是1，但Java对象中却变成了0。这种"数据失真"问题在逻辑删除、枚举映射等场景下尤为常见。

造成这种现象的根本原因在于ORM框架的"中间层处理"特性。MyBatisPlus作为增强版ORM工具，会在以下环节对原始数据施加影响：

• 类型处理器（TypeHandler）进行Java类型与数据库类型的转换
• 字段注解（如@TableField）触发的自动填充机制
• 全局拦截器（如分页插件）对SQL语句的改写
• 逻辑删除标记（@TableLogic）的自动过滤

实际案例：某电商平台订单系统的order_status字段在数据库存储为整数，但通过MyBatisPlus查询后变成了枚举对象。这是由于未统一后端枚举与数据库值的映射关系。

2. 核心原因深度解析

2.1 逻辑删除的"幽灵数据"

当实体类添加@TableLogic注解时，MyBatisPlus会自动在SQL中追加删除条件。例如：

java复制@TableLogic
private Integer deleted;

生成的SQL会变成：

sql复制SELECT * FROM user WHERE deleted = 0 

但开发者直接连接数据库查询时，仍能看到deleted=1的记录。这就造成了"数据不一致"的错觉。

避坑指南：

1. 确保团队所有成员知晓逻辑删除字段的存在
2. 在Swagger等接口文档中明确标注逻辑删除状态
3. 避免在业务代码中硬编码delete_flag=0这类条件

2.2 枚举类型的映射陷阱

MyBatisPlus默认使用枚举的ordinal()值进行存储，这会导致严重问题：

java复制enum Status {
    ENABLED,  // 数据库存0
    DISABLED  // 数据库存1
}

如果调整枚举顺序：

java复制enum Status {
    DISABLED,  // 原代码中1现在变成0
    ENABLED
}

此时数据库中的1会被错误映射为ENABLED状态