1. 从“更新”这个看似简单的操作说起在任何一个涉及数据持久化的项目中增删改查是绕不开的四大基础操作。其中“改”——也就是更新操作其使用频率和复杂程度往往被严重低估。很多开发者尤其是刚接触MyBatis-Plus的朋友可能会觉得更新不就是调用一个updateById吗这有什么好讲的但实际开发中我们遇到的场景远比这复杂你可能需要根据一组复杂的条件批量更新数据你可能在更新时只想修改非空的字段而忽略那些为null的值你可能需要在一个事务里先查询再更新并确保数据的一致性。这些场景如果处理不当轻则导致数据错乱重则引发性能问题甚至业务逻辑漏洞。MyBatis-Plus简称MP作为MyBatis的增强工具在简化单表操作上做到了极致。它的更新API设计得非常巧妙封装了常见且易错的细节。今天我们就来深入聊聊MP中的更新操作核心聚焦在两个最常用也最易混淆的路径上通过主键ID更新和通过条件构造器更新。我会结合自己多年在业务中踩过的坑带你不仅会用更要明白为什么这么用以及在不同场景下如何做出最合适的选择。你会发现一个简单的update方法背后藏着MP设计者对于便捷性、安全性以及性能的诸多考量。2.updateById精准的单点打击当我们手头有一个实体的完整信息并且知道它的主键ID时updateById无疑是最直接、最清晰的选择。这个方法的行为非常明确根据实体对象中的ID字段去更新数据库中对应ID的记录实体中其他非null的字段值会被用于更新。2.1 基础用法与背后的SQL假设我们有一个User实体类其中id字段被TableId标注为主键。User user new User(); user.setId(1L); // 明确指定要更新的记录ID user.setName(张师傅); user.setAge(30); user.setEmail(zhangexample.com); boolean success userService.updateById(user);这段代码执行后MP会生成类似如下的SQL语句UPDATE user SET name张师傅, age30, emailzhangexample.com WHERE id1;这里有一个至关重要的细节MP的updateById以及后续提到的条件更新默认使用的是非null更新策略。也就是说只有你显式在实体对象中set了的、值不为null的字段才会出现在SET子句中。上面的例子中如果User实体还有一个avatar头像字段但我们没有调用setAvatar那么生成的SQL就不会包含avatar字段该字段在数据库中将保持原值。注意这个策略是MP防止误更新的重要安全机制。想象一下如果你从前端接收了一个庞大的表单对象但只想更新其中一两个字段如果MP把所有字段包括null都更新就会意外地将数据库中的其他字段置为null。非null更新策略避免了这个问题。2.2 实战中的“坑”与应对策略虽然updateById很简单但坑也不少。第一个坑ID为空或不存在。如果你不小心将一个id为null或数据库中不存在的实体传给updateById会发生什么MP不会抛出异常而是会执行一条WHERE idnull或WHERE id99999的SQL。这条SQL的UPDATE影响行数为0方法返回false。在业务逻辑中如果你依赖于返回值true来判断更新成功就需要处理这种“静默失败”的情况。通常更健壮的做法是在调用前进行校验或者在更上层通过查询先行判断记录是否存在。第二个坑乐观锁的集成。在高并发场景下直接使用updateById可能导致数据覆盖。这时就需要引入乐观锁。MP提供了优雅的乐观锁支持。首先在实体类的版本号字段上添加Version注解。public class User { // ... 其他字段 Version private Integer version; }然后在更新时你必须确保从数据库查询出的实体对象带有当前的version值MP会自动在WHERE条件中加上AND version #{version}并在SET部分将version设置为version 1。// 1. 先查询出当前数据携带version User dbUser userService.getById(1L); // 2. 修改需要更新的字段 dbUser.setName(新名字); // 3. 执行更新 boolean success userService.updateById(dbUser);生成的SQL会变成UPDATE user SET name新名字, versionversion1 WHERE id1 AND version1;如果这条记录在此期间被其他线程修改过version已经不再是1那么本次更新影响行数将为0返回false。这就实现了并发控制。关键点在于你必须使用从数据库查出的实体对象进行更新而不是new一个新对象只设置ID和要改的字段因为新对象的version是null会导致乐观锁失效。第三个坑字段类型不匹配与动态表名。当你的实体类字段类型与数据库字段类型不完全匹配例如Java中Boolean对应数据库tinyintMP的类型处理器TypeHandler会负责转换通常没问题。但在极少数自定义复杂类型时需要留意。另外如果项目使用了MP的动态表名功能updateById生成的表名也会根据你的规则动态变化这本身不是坑但需要你清楚这个机制避免在分表等场景下更新错表。3.updateWrapper灵活的批量与条件更新updateById适用于单条、已知ID的更新。但更多时候我们的更新条件是动态的、复杂的甚至是批量的。比如“将所有状态为‘未处理’且创建时间超过3天的订单状态改为‘已过期’”。这时就需要祭出update(WrapperT updateWrapper)和update(T entity, WrapperT updateWrapper)这两个强大武器。3.1 条件构造器Wrapper的核心作用Wrapper是MP的灵魂组件之一它用于构建SQL的WHERE条件。在更新场景下它指定了要更新哪些行。场景一纯条件更新设置固定值。例如我们要完成上面提到的订单过期操作。LambdaUpdateWrapperOrder wrapper new LambdaUpdateWrapper(); wrapper.eq(Order::getStatus, 未处理) .lt(Order::getCreateTime, LocalDateTime.now().minusDays(3)); boolean success orderService.update(wrapper);等等这样写对吗不对直接调用update(wrapper)会报错因为它不知道要更新成什么值。这里有两种正确写法写法A使用Wrapper的set方法。LambdaUpdateWrapperOrder wrapper new LambdaUpdateWrapper(); wrapper.eq(Order::getStatus, 未处理) .lt(Order::getCreateTime, LocalDateTime.now().minusDays(3)) .set(Order::getStatus, 已过期); // 在Wrapper中指定SET内容 boolean success orderService.update(wrapper);这种方式生成的SQL是UPDATE order SET status 已过期 WHERE (status 未处理 AND create_time 2023-10-01);它非常适合于将一批数据更新为同一个固定值的场景。写法B使用update(T entity, WrapperT updateWrapper)方法。Order updateEntity new Order(); updateEntity.setStatus(已过期); LambdaUpdateWrapperOrder wrapper new LambdaUpdateWrapper(); wrapper.eq(Order::getStatus, 未处理) .lt(Order::getCreateTime, LocalDateTime.now().minusDays(3)); boolean success orderService.update(updateEntity, wrapper);这种方式生成的SQL是UPDATE order SET status 已过期 WHERE (status 未处理 AND create_time 2023-10-01);效果与写法A一样。那么区别在哪主要在于代码的清晰度和复用性。写法A将所有逻辑条件更新值都集中在了Wrapper中。写法B则将“要更新的数据”entity和“更新的条件”wrapper分离。当更新逻辑更复杂或者entity本身是从其他地方构建而来时写法B会更清晰。场景二基于当前值的更新。有时我们需要进行相对更新比如“给所有VIP用户的积分增加100”。这就需要用到Wrapper的setSql方法。LambdaUpdateWrapperUser wrapper new LambdaUpdateWrapper(); wrapper.eq(User::getVipLevel, 1) .setSql(points points 100); // 直接写入SQL片段 boolean success userService.update(wrapper);生成的SQLUPDATE user SET points points 100 WHERE (vip_level 1);setSql非常强大可以执行任何合法的SQLSET表达式如字符串拼接、调用数据库函数等。但务必注意SQL注入风险确保传入setSql的参数是可信的对于用户输入一定要做严格的过滤和校验。3.2UpdateWrapper与LambdaUpdateWrapper的选择你可能注意到了我上面例子用的都是LambdaUpdateWrapper。MP提供了两种风格的条件构造器UpdateWrapperT基于字符串列名。new UpdateWrapperUser().eq(vip_level, 1).setSql(points points 100);LambdaUpdateWrapperT基于Lambda表达式引用实体类的getter方法。new LambdaUpdateWrapperUser().eq(User::getVipLevel, 1).setSql(points points 100);强烈推荐使用LambdaUpdateWrapper。原因有三类型安全编译器能检查字段名是否正确避免因拼写错误导致的运行时bug。重构友好使用IDE重命名实体类字段时Lambda引用会自动更新字符串列名则不会容易遗漏。代码清晰User::getVipLevel比vip_level更直观尤其是对于驼峰命名字段。除非你的字段名是动态生成的比如来自配置否则没有理由不用Lambda版本。3.3 条件构造的复杂组合与性能考量Wrapper支持and,or,nested嵌套等复杂条件组合。LambdaUpdateWrapperOrder wrapper new LambdaUpdateWrapper(); wrapper.eq(Order::getShopId, 1001) .and(w - w.eq(Order::getStatus, 未支付).or().eq(Order::getStatus, 支付中)) .lt(Order::getCreateTime, LocalDateTime.now().minusHours(1)) .set(Order::getStatus, 已取消);这对应了复杂的WHERE条件shop_id 1001 AND (status 未支付 OR status 支付中) AND create_time ?。但是条件越复杂SQL性能风险就越高。特别是当IN子句包含大量元素或者OR条件导致索引失效时。对于大批量、复杂条件的更新有两点建议分批次更新如果一次要更新数十万条数据不要用一个Wrapper搞定。可以按时间范围、ID范围进行分批例如每次更新5000条循环处理。这能减轻数据库锁压力和事务日志膨胀。审视索引确保WHERE条件中的关键字段如shop_id,create_time有合适的索引。对于status这种低区分度的字段单独建索引意义不大但作为组合索引的一部分可能有效。4. 高级特性与生产实践中的精雕细琢掌握了基本用法我们来看看MP更新操作中那些能提升代码质量和运行效率的高级特性。4.1 全局策略与局部注解控制字段更新行为我们之前提到MP默认使用“非null更新”。这个策略可以通过全局配置或字段注解进行微调。全局配置MybatisPlusProperties在application.yml中可以设置global-config.db-config.update-strategy。它有四个值IGNORED忽略判断所有字段都更新不推荐有数据被意外置null的风险。NOT_NULL只更新非null字段默认值。NOT_EMPTY更新非null且非空的字段对于字符串会检查!null !isEmpty()。DEFAULT同NOT_NULL。 除非有非常特殊的全局需求否则不建议修改默认的NOT_NULL。局部注解TableField在实体类字段上使用TableField(updateStrategy FieldStrategy.XXX)可以覆盖全局策略。这是更常用的方式。public class User { TableField(updateStrategy FieldStrategy.IGNORED) private String remark; // 即使为null更新时也总是包含此字段 TableField(updateStrategy FieldStrategy.NEVER) private String createBy; // 永不参与更新即使set了值也会被忽略 }一个经典场景逻辑删除字段deleted。我们通常会在字段上标注TableField(updateStrategy FieldStrategy.NEVER)因为这条记录是否被删除应该由专门的delete或逻辑删除方法来控制防止在普通的业务更新中被意外修改。4.2 乐观锁与悲观锁的适用边界前面提到了乐观锁Version。它是一种无锁编程思想适合读多写少、冲突不频繁的场景。它的优点是性能好并发度高。缺点是当冲突真的发生时应用层需要处理更新失败返回false通常要重试或提示用户。那么什么时候用悲观锁呢MP本身不直接提供悲观锁API但你可以通过MyBatis的原生注解或XML在查询时使用SELECT ... FOR UPDATE。这适用于写多读少、冲突概率极高、且业务上不允许重试要求强一致性的场景比如秒杀库存扣减。使用悲观锁会降低并发度增加死锁风险所以要非常谨慎。我的经验是优先使用乐观锁。只有在明确知道冲突频率极高且业务逻辑简单、能快速完成事务的情况下才考虑悲观锁。对于库存扣减还有一种更高效的方案是使用数据库的UPDATE table SET stock stock - 1 WHERE id ? AND stock 0利用数据库的行级原子操作这比应用层的锁更轻量。4.3 批量更新的性能陷阱与正确姿势MP的update方法配合Wrapper可以实现批量更新但这里的“批量”指的是一次SQL更新多条记录而不是循环调用多次updateById。错误示范N1问题ListUser userList userService.listByIds(userIds); for (User user : userList) { user.setStatus(INACTIVE); userService.updateById(user); // 循环中执行了N次数据库往返 }如果userIds有1000个就会产生1000条UPDATE语句和1000次网络往返性能极差。正确姿势一次SQL批量更新LambdaUpdateWrapperUser wrapper new LambdaUpdateWrapper(); wrapper.in(User::getId, userIds) // WHERE id IN (1,2,3...) .set(User::getStatus, INACTIVE); userService.update(wrapper);这只会生成并执行一条SQL语句效率有数量级的提升。但是当IN列表非常大比如上万时单条SQL可能过长影响数据库解析性能甚至触达SQL长度限制。这时就需要我们手动进行分批次批量更新。ListLong allIds ... // 上万个ID int batchSize 1000; for (int i 0; i allIds.size(); i batchSize) { ListLong batchIds allIds.subList(i, Math.min(i batchSize, allIds.size())); LambdaUpdateWrapperUser wrapper new LambdaUpdateWrapper(); wrapper.in(User::getId, batchIds) .set(User::getStatus, INACTIVE); userService.update(wrapper); }这样就把一个巨大的更新拆分成多个适度大小的更新批次在效率和可靠性之间取得平衡。4.4 更新操作中的事务管理更新操作尤其是涉及多个步骤的更新如先查后改、更新多张表必须在事务中进行以保证数据一致性。在Spring中最简单的方式是在Service方法上添加Transactional注解。Service public class OrderService { Transactional(rollbackFor Exception.class) public boolean cancelOrder(Long orderId) { // 1. 查询订单 Order order this.getById(orderId); if (!未支付.equals(order.getStatus())) { throw new BusinessException(订单状态不允许取消); } // 2. 更新订单状态 order.setStatus(已取消); boolean updated this.updateById(order); // 3. 释放库存更新另一张表 inventoryService.releaseStock(order.getSkuId(), order.getQuantity()); return updated; } }关键点异常回滚默认Transactional只在遇到RuntimeException和Error时回滚。建议显式指定rollbackFor Exception.class让受检异常也触发回滚。事务传播理解Propagation.REQUIRED默认等传播行为。在上面的例子中如果inventoryService.releaseStock方法也有事务它会加入当前事务。MP方法的事务性MP的updateById、update(wrapper)等方法本身只是执行SQL不开启事务。事务边界需要由Service层的Transactional来控制。5. 自定义update方法应对极端复杂场景尽管MP的封装已经非常强大但总有它覆盖不到的极端场景。比如我们需要根据一个极其复杂的、动态生成的SQL片段来更新或者需要调用数据库特定的函数和语法。这时我们可以退一步使用MyBatis原生的方式或者使用MP的自定义SQL在Mapper层编写XML或注解SQL。5.1 使用Update注解在Mapper接口中可以直接使用MyBatis的Update注解。public interface UserMapper extends BaseMapperUser { Update(UPDATE user SET points points #{increment} WHERE id #{userId}) int incrementPoints(Param(userId) Long userId, Param(increment) Integer increment); }这种方式适合简单、固定的SQL更新。它的优点是直接、清晰。缺点是不支持MP的动态条件构造器SQL是硬编码的。5.2 使用XML映射文件对于极度复杂的更新逻辑XML映射文件是最终武器。首先在Mapper接口中定义方法int complexUpdate(Param(ew) LambdaQueryWrapperUser wrapper, Param(newLevel) Integer newLevel);然后在对应的UserMapper.xml文件中update idcomplexUpdate UPDATE user SET vip_level #{newLevel}, update_time NOW() ${ew.customSqlSegment} !-- 这里可以插入Wrapper动态生成的WHERE条件 -- /update这种方式的强大之处在于混合动力你可以在XML中编写复杂的SET部分包括子查询、CASE WHEN等同时利用MP的Wrapper来动态生成WHERE条件部分通过${ew.customSqlSegment}注入。这既保留了MP条件构造的便利性又获得了原生SQL的表达能力。安全警告注意${ew.customSqlSegment}使用的是${}直接拼接而非#{}预编译。因为Wrapper生成的本身就是安全的SQL片段它使用预编译参数所以这里用${}是安全的。但绝对不要用${}去拼接用户输入的变量那会导致SQL注入。5.3 何时选择自定义更新我的决策路径通常是这样的能用updateById或update(wrapper)解决的绝不用自定义。保持代码简洁统一。当更新逻辑涉及复杂的数据库函数、子查询、特定数据库语法如MySQL的ON DUPLICATE KEY UPDATE时考虑使用Update注解。当更新条件需要MP动态构造但SET部分又极其复杂时使用“XML Wrapper”的混合模式。对于纯粹动态、无法预知的超级复杂SQL才考虑完全手写XML SQL。6. 总结与最佳实践心法回顾一下MP的更新操作看似简单实则门道不少。从最基础的updateById到灵活的条件更新update(wrapper)再到应对复杂场景的自定义SQL它提供了一套完整的工具箱。最后分享几条我在实际项目中总结的、关于更新操作的最佳实践首选Lambda告别字符串坚持使用LambdaUpdateWrapper享受类型安全和重构便利这是提升代码健壮性的最低成本投入。明确策略防止误伤深刻理解并善用FieldStrategy。全局保持NOT_NULL对于特定字段如逻辑删除字段、创建人/时间使用TableField注解显式声明NEVER或IGNORED从机制上杜绝数据被意外覆盖。批量操作分而治之牢记“一次SQL更新多条记录”才是真正的批量更新。面对海量数据时主动进行批次拆分如每1000条一批避免巨型SQL带来的性能问题。乐观锁是并发更新的好朋友在可能发生并发修改的实体上积极使用Version乐观锁。它成本低收益高能有效避免数据覆盖。记得更新时一定要使用携带版本号的实体对象。事务边界要清晰将多个数据库操作特别是查询更新更新多表包裹在同一个Transactional方法中。根据业务需要设置合适的隔离级别和回滚规则。自定义SQL是最后的王牌不要畏惧使用Update或XML当MP的封装无法满足你复杂的业务表达时果断退回到原生SQL。特别是“XML动态SET Wrapper动态WHERE”的混合模式能解决绝大部分复杂更新场景。更新前先思考是否必要这是最重要的心法。很多“更新”操作实际上可以通过插入一条新状态记录事件溯源、或者使用“标记位视图查询”来实现。频繁更新同一行数据尤其是热点数据是数据库性能的常见瓶颈。在设计数据模型时就应考虑数据的可变性有时“以不变应万变”是更高的智慧。 MyBatis-Plus更新操作深度解析：从updateById到条件构造器的实战指南
1. 从“更新”这个看似简单的操作说起在任何一个涉及数据持久化的项目中增删改查是绕不开的四大基础操作。其中“改”——也就是更新操作其使用频率和复杂程度往往被严重低估。很多开发者尤其是刚接触MyBatis-Plus的朋友可能会觉得更新不就是调用一个updateById吗这有什么好讲的但实际开发中我们遇到的场景远比这复杂你可能需要根据一组复杂的条件批量更新数据你可能在更新时只想修改非空的字段而忽略那些为null的值你可能需要在一个事务里先查询再更新并确保数据的一致性。这些场景如果处理不当轻则导致数据错乱重则引发性能问题甚至业务逻辑漏洞。MyBatis-Plus简称MP作为MyBatis的增强工具在简化单表操作上做到了极致。它的更新API设计得非常巧妙封装了常见且易错的细节。今天我们就来深入聊聊MP中的更新操作核心聚焦在两个最常用也最易混淆的路径上通过主键ID更新和通过条件构造器更新。我会结合自己多年在业务中踩过的坑带你不仅会用更要明白为什么这么用以及在不同场景下如何做出最合适的选择。你会发现一个简单的update方法背后藏着MP设计者对于便捷性、安全性以及性能的诸多考量。2.updateById精准的单点打击当我们手头有一个实体的完整信息并且知道它的主键ID时updateById无疑是最直接、最清晰的选择。这个方法的行为非常明确根据实体对象中的ID字段去更新数据库中对应ID的记录实体中其他非null的字段值会被用于更新。2.1 基础用法与背后的SQL假设我们有一个User实体类其中id字段被TableId标注为主键。User user new User(); user.setId(1L); // 明确指定要更新的记录ID user.setName(张师傅); user.setAge(30); user.setEmail(zhangexample.com); boolean success userService.updateById(user);这段代码执行后MP会生成类似如下的SQL语句UPDATE user SET name张师傅, age30, emailzhangexample.com WHERE id1;这里有一个至关重要的细节MP的updateById以及后续提到的条件更新默认使用的是非null更新策略。也就是说只有你显式在实体对象中set了的、值不为null的字段才会出现在SET子句中。上面的例子中如果User实体还有一个avatar头像字段但我们没有调用setAvatar那么生成的SQL就不会包含avatar字段该字段在数据库中将保持原值。注意这个策略是MP防止误更新的重要安全机制。想象一下如果你从前端接收了一个庞大的表单对象但只想更新其中一两个字段如果MP把所有字段包括null都更新就会意外地将数据库中的其他字段置为null。非null更新策略避免了这个问题。2.2 实战中的“坑”与应对策略虽然updateById很简单但坑也不少。第一个坑ID为空或不存在。如果你不小心将一个id为null或数据库中不存在的实体传给updateById会发生什么MP不会抛出异常而是会执行一条WHERE idnull或WHERE id99999的SQL。这条SQL的UPDATE影响行数为0方法返回false。在业务逻辑中如果你依赖于返回值true来判断更新成功就需要处理这种“静默失败”的情况。通常更健壮的做法是在调用前进行校验或者在更上层通过查询先行判断记录是否存在。第二个坑乐观锁的集成。在高并发场景下直接使用updateById可能导致数据覆盖。这时就需要引入乐观锁。MP提供了优雅的乐观锁支持。首先在实体类的版本号字段上添加Version注解。public class User { // ... 其他字段 Version private Integer version; }然后在更新时你必须确保从数据库查询出的实体对象带有当前的version值MP会自动在WHERE条件中加上AND version #{version}并在SET部分将version设置为version 1。// 1. 先查询出当前数据携带version User dbUser userService.getById(1L); // 2. 修改需要更新的字段 dbUser.setName(新名字); // 3. 执行更新 boolean success userService.updateById(dbUser);生成的SQL会变成UPDATE user SET name新名字, versionversion1 WHERE id1 AND version1;如果这条记录在此期间被其他线程修改过version已经不再是1那么本次更新影响行数将为0返回false。这就实现了并发控制。关键点在于你必须使用从数据库查出的实体对象进行更新而不是new一个新对象只设置ID和要改的字段因为新对象的version是null会导致乐观锁失效。第三个坑字段类型不匹配与动态表名。当你的实体类字段类型与数据库字段类型不完全匹配例如Java中Boolean对应数据库tinyintMP的类型处理器TypeHandler会负责转换通常没问题。但在极少数自定义复杂类型时需要留意。另外如果项目使用了MP的动态表名功能updateById生成的表名也会根据你的规则动态变化这本身不是坑但需要你清楚这个机制避免在分表等场景下更新错表。3.updateWrapper灵活的批量与条件更新updateById适用于单条、已知ID的更新。但更多时候我们的更新条件是动态的、复杂的甚至是批量的。比如“将所有状态为‘未处理’且创建时间超过3天的订单状态改为‘已过期’”。这时就需要祭出update(WrapperT updateWrapper)和update(T entity, WrapperT updateWrapper)这两个强大武器。3.1 条件构造器Wrapper的核心作用Wrapper是MP的灵魂组件之一它用于构建SQL的WHERE条件。在更新场景下它指定了要更新哪些行。场景一纯条件更新设置固定值。例如我们要完成上面提到的订单过期操作。LambdaUpdateWrapperOrder wrapper new LambdaUpdateWrapper(); wrapper.eq(Order::getStatus, 未处理) .lt(Order::getCreateTime, LocalDateTime.now().minusDays(3)); boolean success orderService.update(wrapper);等等这样写对吗不对直接调用update(wrapper)会报错因为它不知道要更新成什么值。这里有两种正确写法写法A使用Wrapper的set方法。LambdaUpdateWrapperOrder wrapper new LambdaUpdateWrapper(); wrapper.eq(Order::getStatus, 未处理) .lt(Order::getCreateTime, LocalDateTime.now().minusDays(3)) .set(Order::getStatus, 已过期); // 在Wrapper中指定SET内容 boolean success orderService.update(wrapper);这种方式生成的SQL是UPDATE order SET status 已过期 WHERE (status 未处理 AND create_time 2023-10-01);它非常适合于将一批数据更新为同一个固定值的场景。写法B使用update(T entity, WrapperT updateWrapper)方法。Order updateEntity new Order(); updateEntity.setStatus(已过期); LambdaUpdateWrapperOrder wrapper new LambdaUpdateWrapper(); wrapper.eq(Order::getStatus, 未处理) .lt(Order::getCreateTime, LocalDateTime.now().minusDays(3)); boolean success orderService.update(updateEntity, wrapper);这种方式生成的SQL是UPDATE order SET status 已过期 WHERE (status 未处理 AND create_time 2023-10-01);效果与写法A一样。那么区别在哪主要在于代码的清晰度和复用性。写法A将所有逻辑条件更新值都集中在了Wrapper中。写法B则将“要更新的数据”entity和“更新的条件”wrapper分离。当更新逻辑更复杂或者entity本身是从其他地方构建而来时写法B会更清晰。场景二基于当前值的更新。有时我们需要进行相对更新比如“给所有VIP用户的积分增加100”。这就需要用到Wrapper的setSql方法。LambdaUpdateWrapperUser wrapper new LambdaUpdateWrapper(); wrapper.eq(User::getVipLevel, 1) .setSql(points points 100); // 直接写入SQL片段 boolean success userService.update(wrapper);生成的SQLUPDATE user SET points points 100 WHERE (vip_level 1);setSql非常强大可以执行任何合法的SQLSET表达式如字符串拼接、调用数据库函数等。但务必注意SQL注入风险确保传入setSql的参数是可信的对于用户输入一定要做严格的过滤和校验。3.2UpdateWrapper与LambdaUpdateWrapper的选择你可能注意到了我上面例子用的都是LambdaUpdateWrapper。MP提供了两种风格的条件构造器UpdateWrapperT基于字符串列名。new UpdateWrapperUser().eq(vip_level, 1).setSql(points points 100);LambdaUpdateWrapperT基于Lambda表达式引用实体类的getter方法。new LambdaUpdateWrapperUser().eq(User::getVipLevel, 1).setSql(points points 100);强烈推荐使用LambdaUpdateWrapper。原因有三类型安全编译器能检查字段名是否正确避免因拼写错误导致的运行时bug。重构友好使用IDE重命名实体类字段时Lambda引用会自动更新字符串列名则不会容易遗漏。代码清晰User::getVipLevel比vip_level更直观尤其是对于驼峰命名字段。除非你的字段名是动态生成的比如来自配置否则没有理由不用Lambda版本。3.3 条件构造的复杂组合与性能考量Wrapper支持and,or,nested嵌套等复杂条件组合。LambdaUpdateWrapperOrder wrapper new LambdaUpdateWrapper(); wrapper.eq(Order::getShopId, 1001) .and(w - w.eq(Order::getStatus, 未支付).or().eq(Order::getStatus, 支付中)) .lt(Order::getCreateTime, LocalDateTime.now().minusHours(1)) .set(Order::getStatus, 已取消);这对应了复杂的WHERE条件shop_id 1001 AND (status 未支付 OR status 支付中) AND create_time ?。但是条件越复杂SQL性能风险就越高。特别是当IN子句包含大量元素或者OR条件导致索引失效时。对于大批量、复杂条件的更新有两点建议分批次更新如果一次要更新数十万条数据不要用一个Wrapper搞定。可以按时间范围、ID范围进行分批例如每次更新5000条循环处理。这能减轻数据库锁压力和事务日志膨胀。审视索引确保WHERE条件中的关键字段如shop_id,create_time有合适的索引。对于status这种低区分度的字段单独建索引意义不大但作为组合索引的一部分可能有效。4. 高级特性与生产实践中的精雕细琢掌握了基本用法我们来看看MP更新操作中那些能提升代码质量和运行效率的高级特性。4.1 全局策略与局部注解控制字段更新行为我们之前提到MP默认使用“非null更新”。这个策略可以通过全局配置或字段注解进行微调。全局配置MybatisPlusProperties在application.yml中可以设置global-config.db-config.update-strategy。它有四个值IGNORED忽略判断所有字段都更新不推荐有数据被意外置null的风险。NOT_NULL只更新非null字段默认值。NOT_EMPTY更新非null且非空的字段对于字符串会检查!null !isEmpty()。DEFAULT同NOT_NULL。 除非有非常特殊的全局需求否则不建议修改默认的NOT_NULL。局部注解TableField在实体类字段上使用TableField(updateStrategy FieldStrategy.XXX)可以覆盖全局策略。这是更常用的方式。public class User { TableField(updateStrategy FieldStrategy.IGNORED) private String remark; // 即使为null更新时也总是包含此字段 TableField(updateStrategy FieldStrategy.NEVER) private String createBy; // 永不参与更新即使set了值也会被忽略 }一个经典场景逻辑删除字段deleted。我们通常会在字段上标注TableField(updateStrategy FieldStrategy.NEVER)因为这条记录是否被删除应该由专门的delete或逻辑删除方法来控制防止在普通的业务更新中被意外修改。4.2 乐观锁与悲观锁的适用边界前面提到了乐观锁Version。它是一种无锁编程思想适合读多写少、冲突不频繁的场景。它的优点是性能好并发度高。缺点是当冲突真的发生时应用层需要处理更新失败返回false通常要重试或提示用户。那么什么时候用悲观锁呢MP本身不直接提供悲观锁API但你可以通过MyBatis的原生注解或XML在查询时使用SELECT ... FOR UPDATE。这适用于写多读少、冲突概率极高、且业务上不允许重试要求强一致性的场景比如秒杀库存扣减。使用悲观锁会降低并发度增加死锁风险所以要非常谨慎。我的经验是优先使用乐观锁。只有在明确知道冲突频率极高且业务逻辑简单、能快速完成事务的情况下才考虑悲观锁。对于库存扣减还有一种更高效的方案是使用数据库的UPDATE table SET stock stock - 1 WHERE id ? AND stock 0利用数据库的行级原子操作这比应用层的锁更轻量。4.3 批量更新的性能陷阱与正确姿势MP的update方法配合Wrapper可以实现批量更新但这里的“批量”指的是一次SQL更新多条记录而不是循环调用多次updateById。错误示范N1问题ListUser userList userService.listByIds(userIds); for (User user : userList) { user.setStatus(INACTIVE); userService.updateById(user); // 循环中执行了N次数据库往返 }如果userIds有1000个就会产生1000条UPDATE语句和1000次网络往返性能极差。正确姿势一次SQL批量更新LambdaUpdateWrapperUser wrapper new LambdaUpdateWrapper(); wrapper.in(User::getId, userIds) // WHERE id IN (1,2,3...) .set(User::getStatus, INACTIVE); userService.update(wrapper);这只会生成并执行一条SQL语句效率有数量级的提升。但是当IN列表非常大比如上万时单条SQL可能过长影响数据库解析性能甚至触达SQL长度限制。这时就需要我们手动进行分批次批量更新。ListLong allIds ... // 上万个ID int batchSize 1000; for (int i 0; i allIds.size(); i batchSize) { ListLong batchIds allIds.subList(i, Math.min(i batchSize, allIds.size())); LambdaUpdateWrapperUser wrapper new LambdaUpdateWrapper(); wrapper.in(User::getId, batchIds) .set(User::getStatus, INACTIVE); userService.update(wrapper); }这样就把一个巨大的更新拆分成多个适度大小的更新批次在效率和可靠性之间取得平衡。4.4 更新操作中的事务管理更新操作尤其是涉及多个步骤的更新如先查后改、更新多张表必须在事务中进行以保证数据一致性。在Spring中最简单的方式是在Service方法上添加Transactional注解。Service public class OrderService { Transactional(rollbackFor Exception.class) public boolean cancelOrder(Long orderId) { // 1. 查询订单 Order order this.getById(orderId); if (!未支付.equals(order.getStatus())) { throw new BusinessException(订单状态不允许取消); } // 2. 更新订单状态 order.setStatus(已取消); boolean updated this.updateById(order); // 3. 释放库存更新另一张表 inventoryService.releaseStock(order.getSkuId(), order.getQuantity()); return updated; } }关键点异常回滚默认Transactional只在遇到RuntimeException和Error时回滚。建议显式指定rollbackFor Exception.class让受检异常也触发回滚。事务传播理解Propagation.REQUIRED默认等传播行为。在上面的例子中如果inventoryService.releaseStock方法也有事务它会加入当前事务。MP方法的事务性MP的updateById、update(wrapper)等方法本身只是执行SQL不开启事务。事务边界需要由Service层的Transactional来控制。5. 自定义update方法应对极端复杂场景尽管MP的封装已经非常强大但总有它覆盖不到的极端场景。比如我们需要根据一个极其复杂的、动态生成的SQL片段来更新或者需要调用数据库特定的函数和语法。这时我们可以退一步使用MyBatis原生的方式或者使用MP的自定义SQL在Mapper层编写XML或注解SQL。5.1 使用Update注解在Mapper接口中可以直接使用MyBatis的Update注解。public interface UserMapper extends BaseMapperUser { Update(UPDATE user SET points points #{increment} WHERE id #{userId}) int incrementPoints(Param(userId) Long userId, Param(increment) Integer increment); }这种方式适合简单、固定的SQL更新。它的优点是直接、清晰。缺点是不支持MP的动态条件构造器SQL是硬编码的。5.2 使用XML映射文件对于极度复杂的更新逻辑XML映射文件是最终武器。首先在Mapper接口中定义方法int complexUpdate(Param(ew) LambdaQueryWrapperUser wrapper, Param(newLevel) Integer newLevel);然后在对应的UserMapper.xml文件中update idcomplexUpdate UPDATE user SET vip_level #{newLevel}, update_time NOW() ${ew.customSqlSegment} !-- 这里可以插入Wrapper动态生成的WHERE条件 -- /update这种方式的强大之处在于混合动力你可以在XML中编写复杂的SET部分包括子查询、CASE WHEN等同时利用MP的Wrapper来动态生成WHERE条件部分通过${ew.customSqlSegment}注入。这既保留了MP条件构造的便利性又获得了原生SQL的表达能力。安全警告注意${ew.customSqlSegment}使用的是${}直接拼接而非#{}预编译。因为Wrapper生成的本身就是安全的SQL片段它使用预编译参数所以这里用${}是安全的。但绝对不要用${}去拼接用户输入的变量那会导致SQL注入。5.3 何时选择自定义更新我的决策路径通常是这样的能用updateById或update(wrapper)解决的绝不用自定义。保持代码简洁统一。当更新逻辑涉及复杂的数据库函数、子查询、特定数据库语法如MySQL的ON DUPLICATE KEY UPDATE时考虑使用Update注解。当更新条件需要MP动态构造但SET部分又极其复杂时使用“XML Wrapper”的混合模式。对于纯粹动态、无法预知的超级复杂SQL才考虑完全手写XML SQL。6. 总结与最佳实践心法回顾一下MP的更新操作看似简单实则门道不少。从最基础的updateById到灵活的条件更新update(wrapper)再到应对复杂场景的自定义SQL它提供了一套完整的工具箱。最后分享几条我在实际项目中总结的、关于更新操作的最佳实践首选Lambda告别字符串坚持使用LambdaUpdateWrapper享受类型安全和重构便利这是提升代码健壮性的最低成本投入。明确策略防止误伤深刻理解并善用FieldStrategy。全局保持NOT_NULL对于特定字段如逻辑删除字段、创建人/时间使用TableField注解显式声明NEVER或IGNORED从机制上杜绝数据被意外覆盖。批量操作分而治之牢记“一次SQL更新多条记录”才是真正的批量更新。面对海量数据时主动进行批次拆分如每1000条一批避免巨型SQL带来的性能问题。乐观锁是并发更新的好朋友在可能发生并发修改的实体上积极使用Version乐观锁。它成本低收益高能有效避免数据覆盖。记得更新时一定要使用携带版本号的实体对象。事务边界要清晰将多个数据库操作特别是查询更新更新多表包裹在同一个Transactional方法中。根据业务需要设置合适的隔离级别和回滚规则。自定义SQL是最后的王牌不要畏惧使用Update或XML当MP的封装无法满足你复杂的业务表达时果断退回到原生SQL。特别是“XML动态SET Wrapper动态WHERE”的混合模式能解决绝大部分复杂更新场景。更新前先思考是否必要这是最重要的心法。很多“更新”操作实际上可以通过插入一条新状态记录事件溯源、或者使用“标记位视图查询”来实现。频繁更新同一行数据尤其是热点数据是数据库性能的常见瓶颈。在设计数据模型时就应考虑数据的可变性有时“以不变应万变”是更高的智慧。