Mybatis-plus save()方法详解与性能优化实践

1. Mybatis-plus Save()方法基础认知

第一次接触Mybatis-plus的save()方法时，很多开发者会误以为它只是个简单的INSERT语句封装。实际上这个方法背后隐藏着不少设计巧思，我在实际项目开发中踩过不少坑才真正理解它的完整行为逻辑。

save()方法位于IService接口中，是Mybatis-plus对单条数据持久化的核心封装。与原生Mybatis需要手动编写XML映射不同，它通过实体类注解自动完成ORM映射。但要注意的是，它的行为会根据实体类状态动态变化：

• 当实体ID为空或数据库中不存在相同ID记录时，执行INSERT操作
• 当实体ID非空且数据库存在对应记录时，执行UPDATE操作
• 默认使用实体类全字段进行持久化（除非使用@TableField注解控制）

重要提示：这种自动判断INSERT/UPDATE的设计虽然方便，但在批量操作时可能引发N+1问题，后续会详细说明解决方案。

2. Save()方法的核心陷阱与避坑指南

2.1 ID生成策略的暗坑

Mybatis-plus支持多种ID生成策略，但不同策略与save()方法配合时表现迥异：

java复制// 案例1：ASSIGN_ID策略（开发者手动赋值）
User user = new User();
user.setId(123L); // 明确指定ID
user.setName("测试");
userService.save(user); // 执行UPDATE还是INSERT？

// 案例2：AUTO策略（数据库自增）
User user = new User();
user.setName("测试"); 
userService.save(user); // ID由数据库自动生成

避坑经验：

• 使用ASSIGN_ID时，save()会先执行SELECT检查ID是否存在，存在则UPDATE，否则INSERT
• 使用AUTO自增时，无需setId()，否则可能触发意外UPDATE
• 混合使用不同策略时，建议统一为@TableId(type = IdType.ASSIGN_ID)

2.2 动态表名与租户隔离问题

近期社区热议的"动态取消租户隔离"需求，与save()方法有直接关联。在多租户系统中，如果突然需要跨租户操作数据：

java复制// 错误做法：直接修改实体类租户ID
user.setTenantId("new_tenant"); 
userService.save(user); // 可能触发权限异常

// 正确方案：使用条件构造器临时关闭租户过滤
try {
    TenantHelper.disableTenantFilter();
    userService.save(user);
} finally {
    TenantHelper.enableTenantFilter();
}

实测发现：在3.5.3+版本中，save()方法会校验@TenantId注解字段，即使手动修改也会被拦截。必须配合TenantHelper使用。

3. 批量保存的性能优化方案

虽然save()支持批量操作，但默认实现是循环单条处理：

java复制List<User> users = Arrays.asList(new User(...), ...);
userService.saveBatch(users); // 实际是循环调用save()

性能对比测试（万级数据）：

优化建议：

1. 小批量（<1000条）：使用saveBatch(users, batchSize)控制批处理大小
2. 大批量：实现自定义Mapper方法，使用<foreach>标签真批量插入
3. 极端性能场景：考虑JDBC批处理或LOAD DATA INFILE

4. 字段更新控制的三种姿势

save()默认更新所有字段，但实际业务中常需要精细控制：

4.1 注解排除法

java复制public class User {
    @TableField(update = false)
    private String createTime; // 永不更新
}

4.2 动态Wrapper法

java复制UpdateWrapper<User> wrapper = new UpdateWrapper<>();
wrapper.set("name", "新名字")
       .eq("id", 123);
userService.update(wrapper); // 只更新指定字段

4.3 乐观锁配合法

java复制@Version
private Integer version;

// save()时会自动校验version
userService.save(user); 

血泪教训：曾经因为忘记加@Version注解，导致并发修改数据覆盖。建议关键业务实体必须实现乐观锁。

5. 事务与异常处理实践

save()方法默认不开启事务，这点容易被忽略：

java复制// 错误示例：部分失败导致数据不一致
public void batchSave(List<User> users) {
    users.forEach(userService::save);
}

// 正确方案1：声明式事务
@Transactional
public void safeBatchSave(List<User> users) {
    userService.saveBatch(users);
}

// 正确方案2：编程式事务
public void manualTransaction(List<User> users) {
    TransactionTemplate template = new TransactionTemplate(transactionManager);
    template.execute(status -> {
        try {
            return userService.saveBatch(users);
        } catch (Exception e) {
            status.setRollbackOnly();
            throw e;
        }
    });
}

异常处理要点：

• DuplicateKeyException：检查ID生成策略或唯一索引
• PessimisticLockException：事务隔离级别冲突
• TransactionTimedOutException：批量操作需要调整超时时间

6. 扩展技巧：自定义Save逻辑

有时需要继承默认save()行为：

java复制public class CustomServiceImpl<M extends BaseMapper<T>, T> extends ServiceImpl<M, T> {
    
    @Override
    public boolean save(T entity) {
        // 前置处理
        if (entity instanceof AuditEntity) {
            ((AuditEntity) entity).setCreateTime(LocalDateTime.now());
        }
        
        boolean result = super.save(entity);
        
        // 后置处理
        if (result) {
            log.info("保存成功：{}", entity);
        }
        return result;
    }
}

这种扩展方式在需要统一填充创建人、审计字段时特别有用。我在金融项目中通过这种方式统一处理了十多个实体的审计字段，比AOP方案性能更高。