Mybatis版本升级踩坑及背后原理分析_mybatis从3.4.2升级到3.5.5有风险吗-CSDN博客

本文链接：https://blog.csdn.net/m0_37222553/article/details/106164815

在一次版本升级中，由于Mybatis从3.2.3升级到3.4.6，导致系统出现报警，因为自3.2.4起Mybatis不再支持原有的SQL Mapper用法。经过分析，发现在3.2.4版本后，Mybatis开始启用`parameterType`属性，导致类型不匹配的错误。在3.2.3及以前版本，Mybatis会忽略`parameterType`，而在3.2.4及以后版本则根据该属性构建SQL绑定信息。因此，建议在升级Mybatis时检查XML配置，确保类型匹配，或不设置`parameterType`，以避免类似问题。

摘要由CSDN通过智能技术生成

1、背景

某一天的晚上，系统服务正在进行常规需求的上线，因为发布时，提示统一的pom版本需要升级，于是从 1.3.9.6 升级至 1.4.2.1。
当服务开始上线后，开始陆续出现了一些更新系统交互日志方面的报警，属于系统辅助流程，报警下图所示, 具体系统数据已脱敏，内容是Mybatis相关的报警，在进行类型转换的时候，产生了强转错误。

更新开票请求返回日志, id:{#######}, response:{
  {"code":XXX,"data":{"callType":3,"code":XXX,"msg":"XXXX","shopId":XXXXX,"taxPlateDockType":"XXXXXXX"},"msg":"XXXXX","success":XXXX}}
nested execption is org.apache.ibatis.type.TypeException: Could not set parameters for mapping: ParameterMapping{property='updateTime', mode=IN, javaType=class java.lang.String,
jdbcTyp=null,resultMapId='null',jdbcTypeName='null',expression='null'}.Cause org.apache.ibatis.type.TypeException,Error setting non null parameter #2 with JdbcType null. Try setting a
different Jdbc Type for this parameter or a different configuration property.Cause java.lang.ClassCastException:java.time.LocalDateTime cannot be cast to java.lang.String

报警的一块代码，属于历史功能，失败并不会影响主流程，但在定位期间，会频繁报警，造成一定的干扰，因此当时首先采取回滚操作，将统一的pom版本回滚至历史版本，报警消失，再进行问题的定位和分析。
以下章节是对报警原因的定位及原因详细分析的介绍。

2、报警原因定位

首先是具体的报警原因:

由于mybatis版本由inf-bom引入而来，在inf-bom升级后，由3.2.3 升级至了 3.4.6版本，而Mybatis自3.2.4开始就不支持目前系统内的SQL Mapper的用法，因此上线后，线上出现频繁报警。接下来是定位的过程。

回滚完毕后，开始具体分析报警产生的主要原因，进行了以下几步的排查。

1.查看了报警的Mapper方法，如下代码所示，这个是接收返回参数，根据主键id，更新具体响应内容和时间的代码，入参有3个，类型分别为long, String 和 LocalDateTime

int updateResponse(@Param("id")long id, @Param("response")String response, @Param("updateTime")LocalDateTime updateTime);

2.查看了Mapper方法对应的XML文件，如下代码，对应的parameterType类型是String，而实际参数的类型有Long，有String，也有LocalDateTime。

<update id