MySQL批量更新优化：CASE WHEN与JOIN两种方式对比

做后端这些年，MySQL 的 UPDATE 操作我写过无数次，但真正让我觉得“这玩意儿得认真对待”的，是第一次在业务高峰期跑一个批量更新任务。当时有一批订单状态要改成已取消，大概两万行。我图省事，直接在脚本里 SELECT 出 id，然后 for 循环一条条 UPDATE。结果跑了三分多钟还没结束，连接数飙红，数据库 CPU 直接上去，差点把线上业务拖停。后面复盘了几遍才发现，MySQL 批量 UPDATE 的靠谱姿势其实就两种：一种是用 CASE WHEN 表达式把多行更新压进同一句 SQL，另一种是借助 JOIN 关联一张数据表让 MySQL 自己去匹配。这篇文章把这两种方式的原理、写法、实测结果和坑一次讲清楚，适合正在写数据订正脚本、功能开发中需要批量改状态的后端开发，也适合 DBA 随手翻一翻。

1. 先看场景：为什么“一条条 UPDATE”会被我拉进黑名单

1.1 逐条更新的成本明细

很多人一听到“批量更新”，第一反应是查出来然后 for 循环一条条 UPDATE。数据量只有几十条时没毛病，但一旦变成几千、几万，这条路基本走不通。问题不在于 UPDATE 语句本身，而在于“逐条”两个字叠加出的综合成本。

第一条成本是网络往返。应用和 MySQL 之间每执行一条 SQL，都是一次完整的请求响应。不要小看这个往返，局域网内一次往返可能 0.1ms，跨机房或者用了连接池且连接繁忙时，可能到几毫秒甚至几十毫秒。一万条 UPDATE 就是一万次来回，光网络开销就够喝一壶。

第二条成本是 SQL 解析。MySQL 收到一条 UPDATE，要先做语法解析、权限检查、执行计划生成。这些动作虽然单次只要零点几毫秒，但一万条累加起来就是肉眼可见的耗时。

第三条成本在 InnoDB 层。每一条 UPDATE 都要开启事务、写 undo log、写 redo log、加行锁、提交事务、写 binlog。哪怕更新的是同一行，这些动作一个都少不了。最后还有应用层等待——每一条都是同步调用，延迟线性叠加。

我算过一笔账：假设单条 UPDATE 平均执行 10ms，一万条就是 100 秒；如果数据库繁忙、连接池排队，单条延迟到 50ms，那就是 500 秒。这种任务放业务高峰期跑，基本等于自杀。

1.2 批量更新的核心思路：把 N 次交互压成 1 次

批量 UPDATE 的本质，就是减少客户端和数据库之间的交互次数，把 N 条 SQL 执行合并成一条或少数几条。一条 SQL 更新 5000 行，和 5000 条 SQL 各更新一行，在 InnoDB 内部差异非常明显。

前者只需要一次 SQL 解析、一次事务开启、一次提交；行锁在一条语句内部由 MySQL 统一调度，锁的获取顺序整体可控。后者要频繁切换事务状态，每次提交都要刷一次磁盘，日志写放大非常严重。

当然，这不代表“一条 SQL 更新越多越好”。单条巨型 UPDATE 会带来大事务、锁范围扩大、binlog 体积暴涨等问题，后面会专门讲。批量更新的正确姿态是：合并到一个合理的粒度，比如每批 5000 行，而不是走两个极端。

1.3 适合上批量 UPDATE 的典型场景

从我实际接触的业务看，批量 UPDATE 主要出现在三类场景。第一类是数据订正：历史数据因为 bug 或者需求变更，需要按某个映射关系批量改字段。比如把一批订单的 shop_id 从旧值迁移到新值，这时候新值往往来自另一张表或配置文件。

第二类是业务状态流转：订单超时批量取消、优惠券过期、会员积分清零、用户等级批量调整。这类任务通常是定时任务触发，一跑就是几万行。

第三类是外部数据同步：运营给了一个 Excel 名单，要求更新一批用户的标签；或者说接口批量返回了新的状态，需要回写到业务表。这类场景的数据源在外部，天然适合导入临时表后 JOIN 更新。

有一类场景不适合硬套批量 UPDATE：每次更新都依赖用户实时操作、需要逐行做复杂业务校验的接口。强行合并成一条 SQL 没问题，但业务逻辑会变得极其拧巴，出了问题也难定位。批量更新更应该在离线任务、后台脚本、数据订正这种场景里发光发热。

2. 方式一：CASE WHEN 表达式，把多个更新条件塞进一条 SQL

2.1 最基本的写法

CASE WHEN 方式应该是很多后端开发最早接触的批量更新写法。它的核心思路是：在一条 UPDATE 语句里，通过 CASE 表达式对不同的行分别计算要写入的值。举个例子：

sql复制UPDATE users
SET level = CASE id
    WHEN 10001 THEN 'vip1'
    WHEN 10002 THEN 'vip2'
    WHEN 10003 THEN 'vip3'
END
WHERE id IN (10001, 10002, 10003);

这条 SQL 的含义是：只更新 id 为 10001、10002、10003 的三行，每一行根据自身 id 匹配对应的 WHEN 分支，把 level 分别改成 vip1、vip2、vip3。

MySQL 执行时会先用 WHERE id IN (...) 定位到目标行，然后逐行计算 CASE 表达式，再把结果写回。注意这里 WHERE 条件非常重要，如果不带 WHERE，MySQL 会对全表每一行都计算 CASE，性能不可控，而且可能出现非常严重的副作用。

什么副作用？如果某行的 id 没有出现在任何一个 WHEN 分支里，CASE 表达式的结果就是 NULL，UPDATE 会把这个 NULL 写进 level 字段，等于把原有的值清空了。这是线上最容易踩的坑，后面会细说。

还有另一种写法，适合条件更复杂的场景：

sql复制UPDATE orders
SET order_status = CASE
    WHEN order_id = 101 THEN 'paid'
    WHEN order_id = 102 THEN 'shipped'
    ELSE order_status
END
WHERE order_id IN (101, 102);

这种写法用完整条件表达式替代了简单的等值匹配，而且加了 ELSE order_status，意思是：万一有 WHERE 圈进来但没匹配到任何分支的行，保持原值不变。我个人在做批量更新时几乎都会带 ELSE，宁可多写几个字符，也不想承担字段被清空的风险。

2.2 用代码拼出这条 SQL

实际项目中，我们很少手写这么长的 CASE WHEN，而是通过代码生成。最常见的场景是：应用从接口拿到一个 id 到新值的映射字典，然后批量更新。Python 代码大致长这样：

python复制data = {10001: "vip1", 10002: "vip2", 10003: "vip3"}
id_list = list(data.keys())

when_clauses = " ".join(
    f"WHEN {uid} THEN '{level}'" for uid, level in data.items()
)

sql = (
    "UPDATE users SET level = CASE id "
    f"{when_clauses} END "
    f"WHERE id IN ({','.join(str(i) for i in id_list)})"
)

拼出来就是 2.1 里那条 SQL。代码量不大，但有几个细节必须注意。

第一，id 最好转成 int 再拼进 SQL，不要直接拼接外部字符串。字符串拼接是 SQL 注入的重灾区，批量 UPDATE 的注入面比单条参数化查询更大，因为整段 WHERE 和 SET 都是拼出来的。第二，字符串类型的值要处理引号，比如运营给的名字里可能带单引号，至少要做转义，或者用参数化方式构造。第三，不要用字符串格式化把整个字典直接塞进去，要显式控制 id 列表的长度，防止一次拼出几十万行的巨型 SQL。

2.3 适用边界和 SQL 体量估算

CASE WHEN 方式本质上是把“要更新的数据”塞进 SQL 文本里，所以它的上限直接由 SQL 文本长度决定。每个分支大概长什么样呢？WHEN 10000000 THEN 'vip1' 算上空格大概 25 到 30 字节。5000 行大约 125KB，5 万行大约 1.25MB。默认的 max_allowed_packet 是 64MB，单看很多场景不会爆。

但别只盯着 max_allowed_packet。我实测下来，SQL 文本超过几百 KB 之后，MySQL 解析长 SQL 的 CPU 开销会明显上升。1MB 左右的 SQL，光解析阶段可能就要几十毫秒到上百毫秒。而且这种巨型 SQL 如果出现在慢查询日志里，基本没法看，排查问题会非常痛苦。

binlog 方面也要注意：不管用哪种批量方式，实际更新的行数一样，binlog 内容大小是接近的。但一条巨型 SQL 会导致单个事务过大，提交时对磁盘和主从同步的压力都会集中在一瞬间。综合来看，CASE WHEN 方式我建议控制在 5000 行以内，极限情况不要超过一两万行。

2.4 容易踩的坑：默认值、类型、空值

CASE WHEN 最常见的坑就是忘记 ELSE。前面说过，WHERE 圈进来的行如果没匹配到任何 WHEN 分支，CASE 表达式返回 NULL，UPDATE 会把字段清空。这种事故特别隐蔽，因为 SELECT 验证时往往只关注要更新的那几行，不会去查“WHERE 圈进来但没匹配到”的边缘行。我的习惯是：只要 CASE 表达式无法保证覆盖所有命中行，就一定要加 ELSE 保留原值。

第二个坑是类型转换。如果 id 字段是 varchar，但 CASE WHEN 后面写的是纯数字，MySQL 会对列做隐式转换，可能导致索引失效，全表扫描。同理，被更新的值如果类型不匹配，比如把字符串写进 int 字段，MySQL 会做转换，转换失败就报错，转换成功但不符合预期的情况更坑。

第三个坑是字符集。批量更新内容如果是中文，要确保客户端连接的 character_set_client 和目标表字段的字符集一致，否则很容易乱码。我遇到过从 Excel 读出来的中文经过 pandas 处理后写入，因为编码问题整批更新出乱码，最后只能靠备份恢复。

第四个坑是唯一索引冲突。如果要更新的字段上有唯一索引，而批量数据本身就有重复值，执行时会直接报 Duplicate entry。所以批量更新前，最好先用 SELECT 对目标数据做一次分组计数，看看有没有重复。

3. 方式二：JOIN 关联表，让 MySQL 自己找匹配行

3.1 核心语法和底层逻辑

CASE WHEN 方式是把数据写进 SQL，JOIN 方式则是把数据放进表，让 MySQL 自己去关联。核心语法长这样：

sql复制UPDATE target_table t1
JOIN source_table t2 ON t1.id = t2.target_id
SET t1.status = t2.new_status
WHERE t2.batch_no = '20250101';

也可以把数据源直接写成子查询：

sql复制UPDATE orders t1
JOIN (
    SELECT order_id, new_status
    FROM temp_status
    WHERE batch_no = '20250101'
) t2 ON t1.order_id = t2.order_id
SET t1.order_status = t2.new_status;

底层逻辑上，MySQL 会先根据 JOIN 条件把两边的数据关联起来，生成一个中间结果集，然后对结果集里属于目标表的行逐行执行更新。换句话说，它先通过表关联把“要更新的行”和“新值”配对，再落笔修改。

这种方式的优势很明显。第一，要更新的数据放在表里，不受 SQL 文本长度限制，数据量再大也能处理。第二，关联条件走索引的话，执行效率很高。第三，数据来源如果本身就是表格，天然适合这种模式。第四，临时表里可以留下完整的数据痕迹，事后审计、对账都方便。

3.2 典型实践：Excel 数据导入后替换线上字段

我遇到最多的 JOIN 批量更新场景，就是运营给一个 Excel 名单，要求批量改用户等级或者订单状态。第一步是把 Excel 导入 MySQL 临时表，第二步执行 JOIN UPDATE。下面给一个完整的 Python 示例：

python复制import pymysql
import pandas as pd

df = pd.read_excel("user_level.xlsx")

conn = pymysql.connect(
    host="127.0.0.1",
    user="root",
    password="...",
    database="app_db",
    charset="utf8mb4",
)
cursor = conn.cursor()

# 1. 在会话内创建临时表，user_id 设为主键保证唯一
cursor.execute("""
    CREATE TEMPORARY TABLE temp_user_level (
        user_id BIGINT PRIMARY KEY,
        user_level VARCHAR(20) NOT NULL
    ) ENGINE=InnoDB
""")

# 2. 批量写入临时表
cursor.executemany(
    "INSERT INTO temp_user_level(user_id, user_level) VALUES (%s, %s)",
    df[["user_id", "user_level"]].values.tolist(),
)

# 3. 先看看临时表里有多少数据
cursor.execute("SELECT COUNT(*) FROM temp_user_level")
print("temp rows:", cursor.fetchone()[0])

# 4. 先用 SELECT 验证能关联到多少行，避免直接 UPDATE 后才发现数据对不上
cursor.execute("""
    SELECT COUNT(*) FROM users u
    JOIN temp_user_level t ON u.user_id = t.user_id
""")
print("matched rows:", cursor.fetchone()[0])

# 5. 执行 JOIN UPDATE
cursor.execute("""
    UPDATE users u
    JOIN temp_user_level t ON u.user_id = t.user_id
    SET u.user_level = t.user_level
""")
print("affected rows:", cursor.rowcount)

conn.commit()

# 6. 清理临时表
cursor.execute("DROP TEMPORARY TABLE temp_user_level")

这里我用的是 TEMPORARY TABLE。它的好处是会话级隔离，连接断开自动消失，不会污染业务库，也省得手动清理。但要注意，临时表只在当前连接里可见，如果用连接池且连接被复用，一定要在事务结束后 DROP，否则下一个请求可能看到残留数据。另外一个容易忽略的点是：如果数据量很大，executemany 一次性写入临时表也可能撑爆事务，建议分批写。

3.3 性能关键点：索引、驱动表、唯一性

JOIN UPDATE 能不能跑得快，基本看三点：索引、驱动表、唯一性。

索引是决定性的。临时表的关联键必须建索引，否则每次关联都是全表扫描。上面示例里 user_id 设为主键，天然有索引，所以关联很快。主表这边的关联字段也必须有索引，否则 MySQL 要在主表上逐行判断是否匹配，数据量大时直接报废。我用 EXPLAIN 检查时，重点看 type 列：如果是 ref 或 eq_ref，说明用到索引了；如果是 ALL，说明在扫全表，必须优化。

驱动表的选择也影响性能。MySQL 优化器通常会选择小表作为驱动表，大表作为被驱动表，通过索引去匹配。实际开发中，我们不太需要手动指定驱动表，因为优化器在统计信息准确的情况下已经选得不错。但如果临时表数据量很大而主表很小，可以反过来考虑用 IN 子查询方式，或者对临时表数据先做聚合压缩。

唯一性是个隐藏大坑。如果 source 表里有多行匹配目标表的同一行，UPDATE 会执行多次，最终结果取决于执行顺序，完全不可控。我见过一个案例：临时表里有重复 user_id，不同行给出不同 level，结果用户等级被更新成哪个值全看运气。所以临时表关联键必须设为主键或唯一键，或者在写入前先 GROUP BY 去重。

3.4 一对多和 collation 的坑

除了关联键不唯一，JOIN UPDATE 还有两个容易踩的坑。

第一个是字符集和排序规则不一致。比如主表 user_id 是 utf8mb4_0900_ai_ci，临时表 user_id 是 utf8mb4_general_ci，JOIN 条件虽然能执行，但 MySQL 需要做排序规则转换，结果就是索引可能失效，额外生成临时表，数据量大时性能崩得很厉害。建临时表时最好显式指定和主表完全一致的类型、字符集、collation，别偷懒省略。

第二个是源数据里存在主表没有的记录。JOIN 不会报错，只是匹配不到，等于这行数据在静默丢失。要排查这种情况，可以在执行 UPDATE 之前用 LEFT JOIN + WHERE t2.id IS NULL 找出未匹配的行，确认是忽略还是补充数据。

4. 两种方式实测对比：数据量是唯一的裁判

4.1 测试环境和方法

光讲原理不够，我用本地环境分别跑了一下两种方式。测试环境是 MySQL 8.0.32，InnoDB 引擎，单表 orders 大约 200 万行。表结构不算复杂：id 是主键 bigint，order_no 是 varchar(32)，user_id 是 bigint，order_status 是 tinyint，update_time 是 datetime。

测试目标是批量把指定 id 范围内的 order_status 改成 2。分别用 CASE WHEN 和 JOIN 临时表两种做法，各更新 1 万行、5 万行、20 万行。CASE WHEN 方式是直接把 id 和新值拼成 SQL；JOIN 方式是把 id 写入临时表，再执行 UPDATE JOIN。每组跑三次取中间值，记录耗时和 SQL 体量。

4.2 对比结果

这组数据是单机测试的相对结果，不同机器、不同配置肯定有差异，但趋势很明确：数据量越大，JOIN 加临时表的方式越稳定，耗时增长也更平缓。

为什么 CASE WHEN 在 5 万行时突然变慢？核心瓶颈不在“更新 5 万行”本身，而在于 SQL 文本从 350KB 涨到 1.7MB。MySQL 解析器要处理这个巨大的词法单元，执行计划优化阶段也要花更多时间。真正更新数据时 InnoDB 该做的工作，两种方式其实差不多。

另外，CASE WHEN 拼出的长 SQL 在慢查询日志里非常占地方。有一次线上压测出现慢 SQL，日志里一条几 MB 的 UPDATE 把文件直接顶爆了，想定位是哪个业务发出来的都很麻烦。JOIN 方式的 SQL 文本短，排查起来清爽很多。

4.3 怎么选

综合实测结果，我一般按下面这个思路选择。

更新行数在 5000 以内，CASE WHEN 是最快最直观的。写起来简单，不需要建临时表，适合应用代码里临时算出一批新值的场景。更新行数在 5000 到 5 万之间，如果新值来自另一张表或者文件，JOIN 加临时表更合适；如果只是十几个分支，CASE WHEN 还能勉强用。更新行数超过 5 万，建议直接 JOIN 加临时表，并且一定要分批提交，每批 5000 到 10000 行。

还有两个决策因素。第一，数据源在哪里。如果新值是应用代码里算出来的，CASE WHEN 不需要建表，省事；如果新值是从 Excel、外部表、接口同步来的，JOIN 方式天然跟数据源匹配，还方便事后审计。第二，这个批量任务会不会反复执行。如果每天都要同步一次，把 source 数据放临时表再跑 JOIN，逻辑上更清晰，出问题也容易重跑。

5. 批量 UPDATE 实战中绕不开的现场问题

5.1 Packet too large 的处理

不管用哪种方式，只要单条 SQL 超过 max_allowed_packet，MySQL 就会报 Got a packet bigger than 'max_allowed_packet' bytes。这里说的包大小并不只是 SQL 文本长度，还包括客户端发送协议中附带的数据。批量 UPDATE 时最容易触发这个问题，尤其是 CASE WHEN 拼出几 MB 的 SQL 时。

处理方式有两种。第一种是临时调大参数：SET GLOBAL max_allowed_packet = 536870912，也就是 512MB。但要注意，这个参数客户端和服务器都有，单改服务端不够，连接也要重新建立才能生效。而且部分云数据库不允许全局修改这个参数。

第二种是我更推荐的方式：拆 SQL。把一万行的批量更新拆成两个 5000 行的批次，每个批次一条 UPDATE，循环执行。拆开之后，单个事务更小，锁的持有时间更短，主从同步压力也小，出问题重跑的成本低很多。调大参数只是让大 SQL 能发出去，MySQL 解析大 SQL 的 CPU 开销依然在，属于治标不治本。

5.2 锁等待与死锁

批量 UPDATE 本质上是长事务加大范围行锁。两个批量任务并发时，如果它们以不同顺序更新同一批行，很容易死锁。

我遇到过一个真实场景：一个定时任务把订单状态从 0 改成 1，另一个任务把支付成功的订单从 1 改成 2。两个任务都处理同一批订单，但更新顺序不一致，结果其中一边报出 Deadlock found when trying to get lock，事务自动回滚。

解决思路有三个。第一，尽量固定更新顺序，比如所有批量任务都按主键排序后再更新，减少交叉等待。第二，业务上避免同一时间并发跑多个针对同一批数据的批量任务，加一个分布式锁或者让任务调度串行。第三，如果死锁已经发生，应用层要捕获死锁异常并加入重试机制。死锁是事务型数据库的正常行为，关键是要让系统能自我恢复。

还有一个要注意的点：大批量 UPDATE 即使没死锁，也可能因为持有太多行锁，把其他普通查询堵住。特别是那些走了辅助索引的查询，在更新事务未提交前，可能因为间隙锁和行锁组合而阻塞。所以线上执行大批量更新，尽量放在低峰期。

5.3 大事务与主从延迟

一条 UPDATE 更新 20 万行，单看执行时间可能只有一两秒，但提交时 binlog 要写 20 万行的变更记录，从库要线性回放这些日志。如果从库配置比较弱或者网络带宽有限，主从延迟会肉眼可见地涨上去。

更大的隐患是 undo log 膨胀。在事务执行期间，被更新行的旧版本都要保留在 undo log 里，其他查询如果还在读这些行，走 MVCC 快照时会读取旧版本，可能产生更长的版本链，进而增加查询成本。如果事务长时间不提交，undo log 会占用大量内存和磁盘空间。

解法就是分批加提交。按主键范围切段，比如 WHERE id > start AND id <= end 每段 5000 到 10000 行，一段一个事务。批次之间提交一次，commit 后释放锁和 undo。如果批量更新逻辑比较重，比如每条记录还要触发其他计算，批次之间可以加一个短暂的 sleep，避免瞬间把数据库 IO 打满。

分批之后，即使中间某批失败，前面已提交的批次不用回滚，后面未提交的批次重跑就行，整体可控性大幅提高。具体的批次大小可以测试决定：在测试环境用目标数据量跑一遍，看耗时和锁等待，再调整。

5.4 Rows matched 与 Rows changed 的差异

执行 UPDATE 后，MySQL 客户端会返回 Query OK, 100 rows affected。但这里的 affected rows，在不同驱动和不同连接参数下，含义可能完全不一样。默认情况下，MySQL server 返回的是 changed rows，也就是实际上值发生变化的行数；但如果连接开启了 CLIENT_FOUND_ROWS 标志，返回的是 matched rows，也就是匹配条件的行数，哪怕值没变也算。

这个差异在幂等更新时特别容易误判。比如你执行 UPDATE users SET level = 'vip1' WHERE id IN (...)，其中有一部分用户的 level 本来就是 vip1，那么实际 changed rows 会小于 matched rows。如果你的业务代码用 rowcount 判断“是否成功更新了 N 行”，就会得出错误结论。

在 JDBC 里，可以通过连接参数 useAffectedRows=true 来让 getUpdateCount() 返回 affected rows 而不是 found rows。不管用哪种，我的建议是：批量更新后不要依赖驱动返回的 rowcount 做业务校验，额外跑一条 SELECT COUNT(*) 统计目标行数的最终状态，结果一目了然。

5.5 我自己的批量更新安全流程

最后分享一个我固定使用的离线批量更新流程，能挡住绝大部分事故。

第一步，备份。至少把目标表要改的主键和当前字段值 SELECT 出来存到临时表或备份表。第二步，预检。先跑 SELECT，统计匹配行数、目标行数，确认临时表里没有重复数据。第三步，试跑。只更新 100 行，检查影响行数和结果是否正确。第四步，正式分批跑。每批 5000 到 10000 行，一批一提交，批次之间停顿一下。第五步，复核。跑完之后用 SELECT 对比最终数据，确认所有目标行都更新到位，没有异常变化，再清理临时表。

有一次我靠着这个流程救回一次事故：试跑 100 行的时候发现运营给的数据里 user_id 存在重复，如果直接全量跑，一批用户会被更新成错误等级。正是预检和试跑拦住了问题。批量 UPDATE 这个操作，写 SQL 本身不难，难的是在执行前想清楚数据对不对、会不会影响线上、能不能快速回滚，这几件事比任何语法技巧都重要。