Mybatis更新无生效行问题：MySQL执行正常但Mybatis失效

问题背景 #

Mybatis执行更新操作返回Updates: 0，但相同参数的SQL在MySQL客户端执行可正常生效：

• Mapper方法：

  int updateAnchorIndexByBookId(Map<String, Object> params);
  

• XML配置：

  <update id="updateAnchorIndexByBookId" parameterType="map">
      UPDATE ad_novel_chapter_info
      SET update_time = #{updateTime},
      is_free =
          CASE
          WHEN chapter_index <![CDATA[ < ]]> #{anchorIndex} THEN 1
          ELSE 0
          END
      WHERE book_id = #{bookId}
  </update>
  

• 执行日志：

  ==>  Preparing: UPDATE ad_novel_chapter_info SET update_time = ?, is_free = CASE WHEN chapter_index < ? THEN 1 ELSE 0 END WHERE book_id = ?
  ==> Parameters: 1724333706334(Long), 90(Integer), 9603(Long)
  <==    Updates: 0
  

可能原因及解决办法 #

1. 字段值无变化，MySQL跳过更新

MySQL默认会忽略那些SET子句中字段值与原有值完全一致的更新请求，即使WHERE条件匹配到数据。如果update_time传入的固定值与目标行现有值相同，且is_free经过CASE计算后的结果也和原有值一致，数据库就会返回Updates: 0。
修复方案：

• 改用MySQL动态生成的时间值，确保每次更新都修改update_time：

  SET update_time = NOW(),
  

• 或者在WHERE条件中增加判断，仅更新需要修改的行：

  WHERE book_id = #{bookId}
  AND (is_free != CASE WHEN chapter_index < #{anchorIndex} THEN 1 ELSE 0 END OR update_time != #{updateTime})
  

2. 参数类型与数据库字段类型不匹配

如果数据库中chapter_index或book_id的类型与传入参数类型不兼容，可能导致比较逻辑异常。例如：

• book_id是VARCHAR类型，但传入Long类型，当字符串包含前导零/空格时，隐式转换后的匹配结果会与手动执行SQL时不同；
• chapter_index是DECIMAL类型，传入Integer参数时，比较逻辑可能出现偏差。
  修复方案：
• 检查数据库字段类型，确保Map中传入的参数类型与字段类型完全一致；
• 在XML中显式指定参数的JDBC类型，避免隐式转换问题：

  WHEN chapter_index <![CDATA[ < ]]> #{anchorIndex, jdbcType=INTEGER} THEN 1
  

3. 事务未提交（仅针对结果不可见场景）

如果更新操作在未提交的事务中执行，即使数据库返回更新行数，外部查询也无法看到结果。但此场景下日志的Updates值应为实际更新行数，而非0，仅作为补充排查点。
修复方案：确保操作所在的事务最终执行commit()。

内容的提问来源于stack exchange，提问作者dreamck