单条UPDATE循环执行比CASE合并慢5–10倍以上，因避免重复开销；中小批量用CASE WHEN+WHERE IN最有效，海量数据则用临时表JOIN；务必确保WHERE走索引、事务控制在1k–10k行，并权衡刷盘参数。
单条 UPDATE 循环执行 1000 次，比一条含 CASE 的 UPDATE 慢 5–10 倍以上——这不是理论值，是实测中锁等待、日志刷盘和网络往返叠加后的结果。核心不是“怎么写”，而是“怎么避免重复开销”。
用 CASE WHEN 合并多行更新
这是中小批量（几千行内）最直接有效的方案。本质是把 N 条语句压缩成 1 条，省掉 N−1 次 SQL 解析、权限检查、事务开销和网络往返。
- 必须配合
WHERE id IN (...)，否则CASE会全表扫描每行做判断，性能反降 - 多个字段更新时，每个字段单独写一个
CASE，不要嵌套或复用条件 -
max_allowed_packet限制实际能拼的行数，超长会报Packet too large；建议单次控制在 500–2000 行，视平均字段长度动态调整 - 示例：
UPDATE users SET status = CASE id WHEN 1 THEN 'active' WHEN 2 THEN 'inactive' END, name = CASE id WHEN 1 THEN 'Alice' WHEN 2 THEN 'Bob' END WHERE id IN (1,2)
海量数据（>10 万行）用临时表 + JOIN
当行数上十万，CASE 拼出的 SQL 过长、内存占用高、解析慢，此时应转向基于临时表的方案——它把“应用层逻辑”下推到数据库内部执行，更可控。
- 先
CREATE TEMPORARY TABLE tmp_update (id BIGINT PRIMARY KEY, new_status VARCHAR(20), new_score INT)，注意主键或唯一索引必须建，否则JOIN会变笛卡尔积 -
INSERT INTO tmp_update VALUES (1,'ok',88), (2,'fail',62), ...批量插入，用多值INSERT或LOAD DATA INFILE - 再执行
UPDATE users u JOIN tmp_update t ON u.id = t.id SET u.status = t.new_status, u.score = t.new_score - 临时表需有
CREATE TEMPORARY TABLES权限；若权限受限，改用普通表 + 前缀命名 + 定时清理
别让 WHERE 条件拖垮性能
再快的批量写法，遇上没索引的 WHERE 列，也会退化成全表扫描——这时你不是在批量更新，是在给磁盘做按摩。
- 用
EXPLAIN FORMAT=TREE UPDATE ...确认type是const、ref或range，而非ALL - 复合条件（如
WHERE tenant_id = ? AND status = ?）要建联合索引，顺序按查询频率和区分度排，不盲目按字段名字母序 - 避免在
WHERE中对列使用函数或类型转换，例如WHERE DATE(created_at) = '2024-01-01'会让索引失效 - 批量更新前先
SELECT COUNT(*)验证命中行数是否合理，防止误写条件导致锁全表
事务大小与刷盘参数要平衡
一次提交 100 万行看似高效，但可能触发 long lock、undo log 溢出、甚至夯住整个实例。真正的瓶颈常不在 SQL 写法，而在事务粒度和持久化策略。
- 单个事务建议控制在 1k–10k 行之间；具体值需结合
innodb_log_file_size和业务容忍延迟测试得出 -
innodb_flush_log_at_trx_commit = 2可显著提速（日志仅 write 到 OS cache，不 fsync），但异常断电可能丢 1 秒事务；线上环境慎切，测试环境可试 - 避免在事务里混杂 SELECT（尤其大结果集），InnoDB 的一致性读会拉长 undo log 生命周期，间接拖慢后续更新
- 如果业务允许最终一致，考虑用消息队列异步落库，把强一致性压力从 DB 层移走
最容易被忽略的是：批量更新不是越“大”越好，而是越“准”越好——准，指 WHERE 走索引、数据提前过滤、事务边界清晰；而不是盲目堆行数。很多慢更新，其实第一行就卡住了，后面全是陪跑。
