MyBatis到MyBatis-Plus升级中的类型转换与兼容性问题

1. 从MyBatis到MyBatis-Plus的技术迁移陷阱实录

去年团队里来了个充满干劲的新人，看着MyBatis那堆XML配置文件和重复的CRUD代码就手痒。某天他兴奋地跑来说要把老项目的MyBatis 3.5.0升级到MyBatis-Plus 3.1.1，结果上线后数据库连接池直接炸锅。这出事故让我深刻认识到：框架升级远不止改个依赖版本那么简单。

1.1 环境配置的暗礁

原项目环境：

• MySQL 5.7.36
• MyBatis 3.5.0
• mysql-connector-java 5.1.26

新人直接改了pom.xml：

xml复制<dependency>
    <groupId>com.baomidou</groupId>
    <artifactId>mybatis-plus-boot-starter</artifactId>
    <version>3.1.1</version>
</dependency>

看起来人畜无害的改动，却在首次查询LocalDateTime字段时抛出了致命异常：

code复制Conversion not supported for type java.time.LocalDateTime

1.2 类型转换的版本博弈

问题根源在于MyBatis 3.5.1的类型处理策略变更。通过对比源码发现：

而mysql-connector-java 5.1.26根本不认识LocalDateTime！这就形成了致命链条：

1. MyBatis-Plus 3.1.1强制依赖MyBatis 3.5.1+
2. MyBatis放弃类型转换
3. 旧驱动无法处理新类型

关键教训：任何ORM框架升级都必须检查驱动兼容性，特别是时间类型的处理机制

1.3 连环坑的解决方案

我们分三步解决这个问题：

1. 驱动升级方案对比

最终选择5.1.42版本：

xml复制<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <version>5.1.42</version>
</dependency>

2. 连接池配置调整

yaml复制spring:
  datasource:
    hikari:
      connection-test-query: SELECT 1
      initialization-fail-timeout: 30000

3. 字段类型Fallback方案

java复制@Bean
public ConfigurationCustomizer mybatisConfigurationCustomizer() {
    return configuration -> {
        configuration.getTypeHandlerRegistry()
            .register(LocalDateTime.class, new CustomLocalDateTimeTypeHandler());
    };
}

2. 生产环境中的致命补丁

更戏剧性的是在数据校验环节。原本的"错误"代码反而成了生产环境的保护伞：

2.1 原始校验逻辑

java复制public void validateMainFiles(List<String> fileIds) {
    List<File> files = listFileGenerateLog(fileIds);
    if (files.isEmpty()) { // 错误逻辑：只要有一个文件存在就通过
        throw new IllegalStateException("主文件未生成");
    }
}

这段代码有个隐藏特性：当fileIds包含"4356,abc_{yyyyMMdd}.txt"这样的脏数据时，因为4356文件确实存在，校验竟能通过！

2.2 "修复"引发的灾难

改成正确逻辑后：

java复制public void validateMainFiles(List<String> fileIds) {
    if (listFileGenerateLog(fileIds).size() != fileIds.size()) {
        throw new IllegalStateException("主文件未生成");
    }
}

结果当晚就爆出生产事故——系统拒绝处理所有包含历史脏数据的文件流转请求。

2.3 血泪换来的经验

1. 脏数据处理原则

   • 新增数据严格校验格式
   • 历史数据保持兼容
   • 通过迁移脚本逐步修正

2. 校验逻辑优化方案

java复制public void validateMainFiles(List<String> fileIds) {
    List<String> validIds = fileIds.stream()
        .filter(id -> id.matches("^\\d+$"))
        .collect(Collectors.toList());
    
    if (listFileGenerateLog(validIds).size() != validIds.size()) {
        throw new IllegalStateException("有效主文件未生成");
    }
}

3. 框架升级的黄金准则

经过这次事件，我们团队制定了严格的升级规范：

3.1 风险评估清单

1. [ ] 版本兼容性矩阵验证
2. [ ] 历史脏数据影响分析
3. [ ] 回滚方案准备时间
4. [ ] 监控指标埋点

3.2 必做的检查项

java复制public class UpgradeChecklist {
    // 类型处理测试
    void testDateTimeHandling() {
        // 包含NULL值、各时期时间格式
    }
    
    // 事务边界测试
    void testTransactionRollback() {
        // 模拟异常场景
    }
    
    // 并发压力测试
    void testConcurrentAccess() {
        // 模拟生产流量
    }
}

3.3 灰度发布策略

1. 新老版本并行部署
2. 流量逐步切换比例：
   • 第一天5%流量到新版本
   • 三天内逐步提升到100%
3. 建立实时监控看板：
   • 异常率对比
   • 性能指标对比
   • 业务成功率对比

那次事故后的晨会上，新人低着头说："原来不是所有优化都值得立即做。"组长拍了拍他肩膀："记住，生产环境的代码就像老房子的承重墙，拆之前得先做好支护。"现在这句话已经成了我们团队的技术信条。每次看到LocalDateTime字段，我都会想起那个兵荒马乱的发布日——这大概就是成长的代价吧。