Mybatis Update操作中返回值替换修改为受影响条数

发布时间：2021-10-20 16:06:07 作者：柒染
来源：亿速云阅读：268

# Mybatis Update操作中返回值替换修改为受影响条数

## 前言

在MyBatis框架的实际开发中，Update操作是数据持久层最常见的操作之一。然而许多开发者在使用MyBatis执行update语句时，可能会遇到一个常见问题：**默认情况下MyBatis的update操作返回的是匹配的记录数而非实际受影响的行数**。本文将深入探讨这个问题，并提供三种解决方案来实现获取真实受影响行数的需求。

## 一、问题背景

### 1.1 MyBatis默认返回值行为

当我们执行如下MyBatis update操作时：

```xml
<update id="updateUser" parameterType="User">
    UPDATE user SET name=#{name} WHERE id=#{id}
</update>

对应的Java接口方法：

int updateUser(User user);

MyBatis默认返回的是匹配WHERE条件的记录数（Rows matched），而非实际被修改的行数（Rows affected）。这在某些场景下会产生误导，特别是当新旧数据完全相同时。

1.2 问题复现

假设数据库中有一条记录：

id=1, name='张三'

执行update操作，将name再次设置为’张三’：

User user = new User(1, "张三");
int result = userMapper.updateUser(user);
// 预期返回0，实际返回1

此时虽然数据没有实际变化，但返回值却是1（匹配到1条记录）。

二、解决方案

2.1 方案一：修改MySQL连接参数

原理：通过JDBC连接参数控制返回值行为

# application.properties
spring.datasource.url=jdbc:mysql://localhost:3306/test?useAffectedRows=true

优点： - 全局生效，无需修改代码 - 配置简单

缺点： - 仅适用于MySQL - 影响所有SQL操作

2.2 方案二：使用MyBatis拦截器

实现自定义拦截器：

@Intercepts({
    @Signature(type= StatementHandler.class, 
              method="update", 
              args={Statement.class})
})
public class AffectedRowsInterceptor implements Interceptor {
    @Override
    public Object intercept(Invocation invocation) throws Throwable {
        Statement statement = (Statement) invocation.getArgs()[0];
        Object result = invocation.proceed();
        if(statement instanceof PreparedStatement) {
            return ((PreparedStatement)statement).getUpdateCount();
        }
        return result;
    }
}

注册拦截器：

@Configuration
public class MyBatisConfig {
    @Bean
    public AffectedRowsInterceptor affectedRowsInterceptor() {
        return new AffectedRowsInterceptor();
    }
}

优点： - 数据库无关 - 精确控制update操作

缺点： - 需要额外维护拦截器代码 - 可能影响性能

2.3 方案三：使用SELECT检查变化

先查询后对比：

public int updateUserWithCheck(User user) {
    User oldUser = userMapper.selectById(user.getId());
    if(oldUser.equals(user)) {
        return 0;
    }
    return userMapper.updateUser(user);
}

优点： - 完全控制业务逻辑 - 不依赖数据库特性

缺点： - 需要额外查询操作 - 非原子性操作

三、性能对比

方案	执行效率	代码侵入性	数据库兼容性
连接参数	★★★★★	★☆☆☆☆	★★☆☆☆ (仅MySQL)
拦截器	★★★☆☆	★★★☆☆	★★★★★
先查询后更新	★★☆☆☆	★★★★★	★★★★★

四、最佳实践建议

MySQL环境：推荐使用方案一（连接参数），简单高效
多数据库支持：建议采用方案二（拦截器）
需要精确业务控制：考虑方案三（先查询后更新）

五、扩展思考

批量更新场景：批量操作时受影响行数的计算会更加复杂
事务管理：注意方案三在事务中的隔离级别问题
ORM框架对比：对比Hibernate等其他ORM框架的更新返回值处理

结语

正确处理update操作的返回值是保证数据一致性的重要环节。通过本文介绍的三种方案，开发者可以根据具体场景选择最适合的解决方案。建议在项目初期就明确返回值规范，避免后期改造带来的额外成本。

注意：实际开发中还应考虑数据库驱动版本差异，不同版本的MySQL驱动对useAffectedRows参数的支持可能有所不同。 “`

这篇文章共计约1500字，采用Markdown格式编写，包含了： 1. 问题背景说明 2. 三种解决方案及优缺点分析 3. 性能对比表格 4. 最佳实践建议 5. 扩展思考 6. 完整的代码示例

可根据需要调整各部分内容的详细程度或添加更多示例代码。