在企业级应用中，MyBatis批量更新是提升写入吞吐、降低数据库交互成本的关键能力。本文围绕三种常见实现，从< strong>适用场景、性能对比以及实战代码等维度展开，帮助你在不同场景下快速落地并做出取舍，提升系统的写入效率与稳定性。
方法一：逐条更新实现批量更新
适用场景
当批量数据规模较小、更新字段简单且对原子性要求不高时，逐条更新是最直接的实现方式。它的优点是实现简单、易于维护，无需复杂的SQL和额外的数据库对象开销，快速上线。对于短时间内的小批量变更，这种方案的< strong>开发成本低、风控简单特性尤为明显。
在开发初期或原型阶段，使用逐条UPDATE可以快速验证业务逻辑与数据结构。但需要注意的是，网络往返次数和日志开销可能成为瓶颈，当并发度提升、批量规模增大时，性能优势会逐步削弱。
性能对比
与单次大规模更新相比，多条UPDATE语句的总执行时间包含多次网络往返和事务日志写入，因此在高并发场景下往往不如合并成少量语句的方案。该方法的吞吐量可随单次更新规模下降而增加，但总体成本随批量增大而快速提升。
另一方面，数据库对多语句的优化能力有限，执行计划的稳定性可能随数据分布而波动，造成偶发性性能波动。若你的数据库连接池与事务边界设计良好，仍可把这方案作为低风险、易维护的选项。
实战代码
以下为基于 MyBatis 的XML实现示例，使用foreach遍历列表，生成多条独立的 UPDATE 语句，批量执行：
<update id="batchUpdateSimple" parameterType="java.util.List"><foreach collection="list" item="item" separator=";">UPDATE t_userSET name = #{item.name}, age = #{item.age}, email = #{item.email}WHERE id = #{item.id}</foreach>
</update>相关的 Java 接口定义如下，便于在服务层直接传入批量数据：
public interface UserMapper {void batchUpdateSimple(@Param("list") List<UserUpdate> updates);
}
方法二：单条 UPDATE 搭配 CASE WHEN 的批量更新
适用场景
当需要对多条记录的不同字段赋予不同的值时，CASE WHEN 案例成为高效的单条 UPDATE 方案。通过在一个 UPDATE 语句中用CASE WHEN为每个 id 指定相应的字段值，可以极大地减少网络往返和数据库锁争用，适合大规模但字段更新较为分散的场景。
该方法的核心在于把多次更新合并成一次数据库操作，但实现的 SQL 会比较复杂，SQL 拼接和动态参数绑定需要仔细处理，以避免注入风险和语法错误。
性能对比
单条 UPDATE 搭配 CASE WHEN 在减少语句总数的同时扩大了单次语句的工作量，因此对网络开销有明显下降，但生成的 SQL 较长、解析成本上升，需要数据库优化器对复杂 CASE 做好优化。对于中等规模以上的批量更新，通常能带来显著的性能提升。
在高并发情景下，这种方式还能减少锁的粒度和锁等待时间，但需要确保 CASE WHEN 语句的可维护性和可读性，避免原地难以排错。
实战代码
下面给出一个 MyBatis XML 的实现，利用 CASE WHEN 为不同记录赋不同值：
<update id="batchUpdateCase" parameterType="java.util.List">UPDATE t_userSETname = CASE idWHEN ${row.id} THEN #{row.name}</foreach>END,age = CASE idWHEN ${row.id} THEN #{row.age}</foreach>ENDWHERE id IN#{row.id}</foreach>
</update> 配套的数据模型示例：
public class UserUpdate {private int id;private String name;private int age;// getters/setters
}调用端示例：
orderMapper.batchUpdateCase(updates);方法三：通过临时表/JOIN 实现的批量更新
适用场景
当批量规模非常大、并且希望以一次性完成多行更新来最大化数据库吞吐时，临时表/JOIN 的方案最具优势。它在需要批量对多行进行多字段更新且数据库对 JOIN 更新友好时表现最佳，且可以配合事务控制确保原子性。
该方法通常需要一定的数据库对象准备（临时表/派生表），以及在 MyBatis 端组织一段批量数据写入临时表再执行 JOIN 更新的流程，相对复杂，但能显著降低网络开销和日志压力。
性能对比
相比逐条更新与 CASE WHEN，JOIN/临时表方案在大批量更新时往往实现更高的吞吐，因为数据库可以在单次执行中优化多行数据的读写路径、减少锁争用，并降低网络往返次数。
需要注意的是，临时表的创建和销毁需要成本，同时要确保在同一事务中完成，否则可能导致数据不一致。因此，该方法更适合具备较强事务与并发控制能力的场景。
实战代码
以下示例展示了 MySQL 环境中，通过临时表来实现批量更新的完整流程，包含创建临时表、插入数据、JOIN 更新以及清理：
-- MySQL 示例
CREATE TEMPORARY TABLE tmp_update (id INT PRIMARY KEY,name VARCHAR(100),age INT
);INSERT INTO tmp_update (id, name, age)
(#{row.id}, #{row.name}, #{row.age})
;UPDATE t_user u
JOIN tmp_update t ON u.id = t.id
SET u.name = t.name, u.age = t.age;DROP TEMPORARY TABLE tmp_update;若使用 PostgreSQL，可以利用 VALUES 构造临时结果集并进行 UPDATE FROM 的方式：
-- PostgreSQL 示例
WITH v(id, name, age) AS ((#{row.id}, #{row.name}, #{row.age})
)
UPDATE t_user AS u
SET name = v.name, age = v.age
FROM v
WHERE u.id = v.id;在 MyBatis 的实际使用中，可以将上述 SQL 封装为一个复杂的脚本，将数据批量写入临时表的部分放在一个子操作中，再执行一次 JOIN 更新即可。
