优先用CASE WHEN处理少量硬编码值更新，用JOIN处理来自关联表的大批量动态更新；二者均需WHERE精确限定范围、索引优化及测试验证。
用 CASE WHEN 实现单条 UPDATE 语句批量更新不同值
当你要根据主键或条件，为每行设置不同的新值时，CASE WHEN 是最直接、最安全的方式。它本质是把「多条 UPDATE」压缩成一条，避免循环或多次执行。
常见错误是漏写 ELSE 或写错匹配逻辑，导致意外置为 NULL；另外，CASE 表达式里不能直接引用子查询（除非用派生表或 CTE）。
示例：给用户表按 ID 批量更新等级
UPDATE users SET level = CASE id WHEN 101 THEN 'VIP' WHEN 102 THEN 'PREMIUM' WHEN 103 THEN 'GOLD' ELSE level -- 关键！不加这句，id 不匹配的行 level 全变 NULL END WHERE id IN (101, 102, 103);
-
WHERE子句必须加上，否则全表扫描 + 全表更新，风险极高 - 每个
WHEN后面只能跟确定值（如字面量、列名），不能跟表达式如id > 100—— 那得用WHEN id > 100 THEN ... - MySQL / PostgreSQL / SQL Server 都支持，但 SQLite 的
CASE在 UPDATE 中行为略有差异（建议加WHERE显式限定）
用 JOIN（或 FROM）实现基于关联表的批量更新
当你有一张「更新映射表」（比如 Excel 导入的临时表、另一张配置表），需要用它驱动主表更新，JOIN 方式更清晰、可读性更强，也便于加条件过滤。
注意：不同数据库语法差异大——MySQL 用 UPDATE ... JOIN，PostgreSQL 用 UPDATE ... FROM，SQL Server 用 UPDATE ... FROM（但需别名），别混用。
示例（MySQL）：用临时表 tmp_updates 更新 products 的价格
UPDATE products p
JOIN tmp_updates t ON p.id = t.product_id
SET p.price = t.new_price,
p.updated_at = NOW()
WHERE t.status = 'active';- 必须给被更新表起别名（如
p），且SET中要带别名，否则报错 -
WHERE放在JOIN后，能提前过滤掉不需要更新的关联行，比在SET里加条件更高效 - PostgreSQL 写法不同：
UPDATE products SET price = t.new_price FROM tmp_updates t WHERE products.id = t.product_id AND t.status = 'active'
什么时候该选 CASE WHEN，什么时候该用 JOIN？
核心看数据来源：值是硬编码 or 来自另一张表。
- 值来自程序变量、Excel 列、少量固定规则 → 优先
CASE WHEN，简单可控，无额外建表成本 - 值来自已有业务表、CSV 导入的中间表、需要 join 多张表计算 → 必须用
JOIN（或FROM），否则要先查再循环，性能崩盘 - 如果映射关系超过几百行，
CASE WHEN会严重降低可维护性，SQL 变成“不可读长字符串”，这时即使没现成表，也建议先CREATE TEMP TABLE装数据再 JOIN
一个容易忽略的点：CASE WHEN 更新在事务中是原子的，而用程序循环执行多条 UPDATE，一旦中断就可能部分成功；JOIN 方式同样是一条语句，也是原子的。
性能与锁注意事项
两种方式都会走全表扫描（除非 WHERE 条件能命中索引），但锁行为有差别。
-
CASE WHEN+WHERE id IN (...)：只锁匹配的行，影响小 -
JOIN更新：如果关联表没索引，或ON字段没索引，可能触发主表全表扫描 + 锁全表（尤其 MySQL 的 InnoDB） - 务必确保
JOIN条件字段（如products.id和tmp_updates.product_id）都有索引，否则慢到超时 - 大表更新前，先用
EXPLAIN看执行计划，确认是否走了索引，有没有 Using temporary / Using filesort
真正上线前，永远在测试库用 SELECT 模拟一遍 JOIN 结果，确认更新范围和数量 —— 多更新一行都可能引发线上事故。
