MySQL批量更新多列时，每列必须单独写CASE WHEN，不可元组赋值；漏分支且无ELSE会导致该列变NULL；类型须一致，大列表建议分批或JOIN临时表。
UPDATE 多列时每个字段都要单独写 CASE WHEN
MySQL 不支持「一行一对象」式批量赋值，哪怕你只想更新 name 和 score 两列，也得给每列各写一套 CASE id ... END。漏掉任意一列的分支，该列就会被设为 NULL（除非加 ELSE 显式保留原值）。
常见错误是以为可以这样写：UPDATE t SET (name, score) = CASE id WHEN 1 THEN ('a', 90) ... END——语法直接报错，MySQL 不支持元组赋值。
-
SET后面必须是「字段 = 表达式」的独立组合，不能合并 - 所有
CASE分支返回值类型要一致，比如score列是INT，就不能混入字符串'90'（会触发隐式转换，可能截断或报错） - 如果某行只更新部分字段，其他字段又不想变，
ELSE必须写成ELSE old_column，不能省略
UPDATE users SET name = CASE id WHEN 1 THEN 'Alice' WHEN 2 THEN 'Bob' ELSE name END, score = CASE id WHEN 1 THEN 85 WHEN 2 THEN 92 ELSE score END WHERE id IN (1, 2);
用 JOIN 临时表实现带计算逻辑的批量更新
当新值依赖复杂计算（比如 base_salary * bonus_rate + adjustment）、或来自外部数据源（CSV/Excel 导入结果），硬编码 CASE 就难维护。这时应走 UPDATE ... JOIN 路线，把计算逻辑放在临时表或派生表里。
关键限制：MySQL 禁止在 UPDATE 中直接 JOIN 子查询（报错 You can't specify target table for update in FROM clause），必须包装成带别名的派生表。
- 临时表需有主键或唯一索引（如
id），否则JOIN可能产生笛卡尔积 -
JOIN条件字段（如t.id = tmp.id）必须已建索引，否则大表更新会全表扫描 - 不建议在生产 SQL 中拼接大子查询；优先
CREATE TEMPORARY TABLE+INSERT+INDEX，再UPDATE JOIN
CREATE TEMPORARY TABLE tmp_update AS SELECT 1 AS id, 5000 * 1.2 + 200 AS new_salary, '2026-Q3' AS period UNION ALL SELECT 2, 5500 * 1.15 + 300, '2026-Q3'; <p>ALTER TABLE tmp_update ADD PRIMARY KEY (id);</p><p>UPDATE users u JOIN tmp_update t ON u.id = t.id SET u.salary = t.new_salary, u.period = t.period;
WHERE id IN (...) 长度超限或性能骤降怎么办
IN 列表超过 1000 项时，SQL 字符串可能突破 max_allowed_packet，或优化器放弃使用索引转为全表扫描。这不是理论风险——实测 5000 行的 IN 列表，在无索引时会让 UPDATE 卡住数秒甚至触发锁等待。
- 务必确认
WHERE字段（如id）已有索引；用EXPLAIN验证是否命中key - 单次更新超过 2000 行，建议拆成每批 500–1000 行，用事务包裹：
START TRANSACTION; ... COMMIT; - 避免在循环里拼
CASE分支生成超长 SQL；PHP/Python 中可分块构建多条短语句，比一条巨长语句更稳
计算值含函数或子查询时的坑
想在 CASE WHEN 里调用 NOW()、(SELECT ...) 或变量？可以，但行为容易误判：
-
NOW()在整条UPDATE执行开始时求值一次，不是每行都刷新 - 子查询若未加限制（如
SELECT max(score) FROM users WHERE dept='A'），会在每次WHEN分支中重复执行，严重拖慢速度 - 用户变量（如
@row := @row + 1）在UPDATE中行为不稳定，MySQL 8.0+ 已明确不推荐用于赋值场景
真正需要逐行动态计算（比如排名、累计值），别硬塞进 CASE；先用窗口函数算出结果存临时表，再 JOIN 更新——这是唯一可控路径。
