JjjjjNP1. 问题现象与背景分析
最近在项目中使用MyBatisPlus时遇到了一个诡异现象：通过Mapper查询出的实体对象数据与数据库表中的实际记录不一致。比如数据库里某条记录的status字段值为1，但通过MyBatisPlus查询出来后却变成了0。这种数据不一致问题在开发中相当危险，可能导致业务逻辑出现严重错误。
经过排查，发现这类问题通常与以下几个因素相关：
- 逻辑删除注解
@TableLogic的误用 - 字段自动填充机制的干扰
- 二级缓存或本地缓存的数据过期
- 自定义TypeHandler处理不当
- 事务隔离级别导致的脏读
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 逻辑删除导致的差异分析
2.1 @TableLogic的工作原理
@TableLogic是MyBatisPlus提供的逻辑删除注解，它的典型配置如下：
java复制@TableLogic
private Integer deleted;
当启用逻辑删除后，MyBatisPlus会自动在所有查询语句后追加WHERE deleted=0条件。如果数据库中的deleted值为1，查询时会自动过滤掉该记录。但更隐蔽的问题是：即使通过其他方式查出了记录，@TableLogic注解的字段也会被自动填充为默认值。
2.2 典型问题场景
假设数据库表结构如下：
sql复制CREATE TABLE user (
id BIGINT PRIMARY KEY,
name VARCHAR(50),
deleted TINYINT DEFAULT 0 COMMENT '0未删除 1已删除'
);
当执行以下操作时会出现数据不一致：
- 直接通过SQL更新：
UPDATE user SET deleted=1 WHERE id=1 - 然后通过MyBatisPlus查询：
java复制User user = userMapper.selectById(1L); System.out.println(user.getDeleted()); // 输出0而非数据库中的1
这是因为MyBatisPlus在结果映射阶段会强制将@TableLogic字段设置为未删除状态。
2.3 解决方案
- 统一删除操作：所有删除操作必须通过MyBatisPlus的delete方法执行
- 禁用自动填充：在配置中关闭逻辑删除自动填充
yaml复制mybatis-plus: global-config: db-config: logic-not-delete-value: 1 logic-delete-value: 0 logic-delete-field: deleted logic-delete-fill-strategy: ignore - 自定义SQL处理：对于需要直接操作SQL的场景，手动处理逻辑删除字段
3. 字段自动填充机制的影响
3.1 MetaObjectHandler的干扰
MyBatisPlus的自动填充功能可能覆盖数据库实际值。例如配置了：
java复制@Component
public class MyMetaObjectHandler implements MetaObjectHandler {
@Override
public void insertFill(MetaObject metaObject) {
this.strictInsertFill(metaObject, "version", Integer.class, 0);
}
@Override
public void updateFill(MetaObject metaObject) {
this.strictUpdateFill(metaObject, "version", Integer.class, 1);
}
}
当从数据库查询出version=5的记录时，如果Mapper方法被误标记为@Update或@Insert，自动填充机制会错误地覆盖该字段值。
3.2 排查方法
- 检查实体类字段是否有
@TableField(fill = FieldFill.INSERT/UPDATE) - 在调试模式下观察
MetaObjectHandler的调用栈 - 对比SQL日志中的返回值和最终对象值
4. 缓存导致的数据不一致
4.1 二级缓存问题
MyBatis二级缓存可能导致脏数据读取。当其他会话更新数据库后，当前会话可能仍读取到缓存中的旧值。
解决方案：
java复制@Mapper
@CacheNamespace(flushInterval = 60000) // 明确设置缓存刷新间隔
public interface UserMapper extends BaseMapper<User> {
}
4.2 本地缓存示例
以下代码演示了错误的缓存使用方式：
java复制// 错误示例：使用HashMap做本地缓存
private static Map<Long, User> cache = new HashMap<>();
public User getCachedUser(Long id) {
return cache.computeIfAbsent(id,
k -> userMapper.selectById(k)); // 数据库更新后缓存不会自动失效
}
正确做法是使用支持过期的缓存库如Caffeine：
java复制private LoadingCache<Long, User> cache = Caffeine.newBuilder()
.expireAfterWrite(5, TimeUnit.MINUTES)
.build(userMapper::selectById);
5. 事务隔离与数据可见性
5.1 隔离级别影响
在READ_UNCOMMITTED隔离级别下，可能读取到其他事务未提交的修改。而当该事务回滚后，就会出现内存数据与数据库不一致的情况。
建议配置：
yaml复制spring:
datasource:
hikari:
transaction-isolation: READ_COMMITTED
5.2 事务传播行为
错误的事务传播可能导致嵌套事务读取到中间状态：
java复制@Transactional
public void updateUser(User user) {
userMapper.updateById(user);
auditService.logUpdate(user); // 如果auditService使用REQUIRES_NEW
}
6. 其他常见问题排查
6.1 TypeHandler映射错误
当数据库字段类型与Java类型不匹配时，自定义TypeHandler可能导致数据转换错误。例如：
java复制@TableField(typeHandler = JsonTypeHandler.class)
private List<String> tags;
如果数据库实际存储的是非法JSON格式，查询时可能静默返回空列表而非报错。
6.2 字段命名策略冲突
MyBatisPlus的字段命名策略（如under_score转camelCase）可能导致列映射失败。可通过以下配置检查：
yaml复制mybatis-plus:
configuration:
log-impl: org.apache.ibatis.logging.stdout.StdOutImpl
7. 系统化排查流程
当遇到数据不一致问题时，建议按以下步骤排查：
-
确认数据库实际值：
java复制// 使用原生JDBC验证 try (Connection conn = dataSource.getConnection(); Statement stmt = conn.createStatement()) { ResultSet rs = stmt.executeQuery("SELECT * FROM table WHERE id=1"); ResultSetMetaData meta = rs.getMetaData(); // 打印所有列值 } -
检查MyBatisPlus日志：
yaml复制logging: level: com.baomidou.mybatisplus: DEBUG -
验证实体类映射：
- 检查
@TableName、@TableField注解 - 确认没有重复的字段映射
- 验证TypeHandler是否正确配置
- 检查
-
排除拦截器干扰：
java复制// 临时移除所有自定义拦截器 @SpringBootTest(properties = "mybatis-plus.configuration.interceptors=") public class DataConsistencyTest {} -
对比不同查询方式：
java复制// 对比BaseMapper查询与原生查询 User mpUser = userMapper.selectById(1L); User rawUser = userMapper.rawSelectById(1L); // 自定义XML方法
8. 预防措施与最佳实践
-
统一数据访问层：
- 禁止绕过MyBatisPlus直接操作数据库
- 对必须的SQL脚本建立评审机制
-
完善的监控体系：
java复制// 实现自定义拦截器监控数据不一致 @Intercepts(@Signature(type=Executor.class, method="query", args={MappedStatement.class, Object.class, RowBounds.class, ResultHandler.class})) public class DataConsistencyInterceptor implements Interceptor { @Override public Object intercept(Invocation invocation) throws Throwable { Object result = invocation.proceed(); // 对比result与数据库原始值 return result; } } -
自动化测试验证：
java复制@Test public void testDataConsistency() { User original = userMapper.selectById(1L); em.flush(); // 确保Hibernate等ORM同步状态 Map<String, Object> dbData = jdbcTemplate.queryForMap( "SELECT * FROM user WHERE id=1"); assertThat(original.getName()).isEqualTo(dbData.get("name")); } -
关键操作日志记录：
java复制@Aspect @Component public class DataAccessLogger { @Around("execution(* com..mapper.*.*(..))") public Object logDataAccess(ProceedingJoinPoint pjp) throws Throwable { Object result = pjp.proceed(); if (result != null) { log.debug("Operation: {}, Result: {}", pjp.getSignature(), JsonUtils.toJson(result)); } return result; } }
在实际项目中，我建议建立定期的数据一致性校验任务，特别是对核心业务表。可以通过Spring Scheduler定时执行校验逻辑，早期发现潜在的数据不一致问题。