直接写set a = b, b = a无法互换，因右侧表达式均取原始值，导致两列都被设为原b值；而case when在单次扫描中基于原始值独立求值，可安全实现互换。
UPDATE 里用 CASE WHEN 互换两列值，为什么直接写 SET a = b, b = a 不行？
因为 SQL 的 SET 子句中所有右侧表达式在语句执行开始时就已求值，a 和 b 都取的是原始值。所以 SET a = b, b = a 实际上等价于把两列都设成原来的 b 值——不是互换，是覆盖。
真正要互换，必须让两个赋值“看到彼此更新前的状态”，而 CASE WHEN 在单次扫描中按条件动态计算，天然满足这个要求。
- 适用于 MySQL、PostgreSQL、SQL Server、Oracle 等主流数据库（语法一致）
- SQLite 不支持在
UPDATE中直接用CASE WHEN对同一行多列做依赖赋值，需改用临时变量或子查询 - 别名不能用于
SET右侧，必须用原字段名或完整表名前缀
互换两列的最小可行写法：用 CASE WHEN + 常量条件
最常用场景是交换同一张表中两个字段（如 first_name 和 last_name），不需要判断逻辑，只靠固定映射：
UPDATE users SET first_name = CASE WHEN 1=1 THEN last_name END, last_name = CASE WHEN 1=1 THEN first_name END;
这里 WHEN 1=1 是恒真条件，确保每行都走对应分支；CASE 表达式各自独立求值，读取的是该语句开始时的原始列值。
- 不要写
ELSE first_name或ELSE NULL——除非你明确需要保底逻辑，否则冗余且可能引入空值 - 如果只对部分行互换（比如仅
status = 'pending'的记录），就把条件加到WHERE子句，而不是塞进CASE - 字段类型要兼容，比如不能把
INT列和DATE列互换，会报类型转换错误
带条件的列值切换：比如根据状态翻转启用/禁用标志
更典型的用途不是“物理互换”，而是按业务规则切换值——例如把 is_active 从 0 变 1、1 变 0：
UPDATE products SET is_active = CASE WHEN is_active = 1 THEN 0 WHEN is_active = 0 THEN 1 ELSE is_active END WHERE id IN (101, 102, 103);
这种写法比 is_active = 1 - is_active 更安全，尤其当字段允许 NULL 或非 0/1 值时。
-
ELSE分支建议保留，防止意外值导致整列被置为NULL - 若用布尔类型（如 PostgreSQL 的
BOOLEAN），可写CASE WHEN is_active THEN FALSE ELSE TRUE END，语义更清晰 - 避免在
CASE中调用函数（如NOW()、RAND()）多次，每次都会重新执行
多个字段联动更新时，CASE 的求值顺序不重要，但字段依赖关系要小心
当你同时更新三列，且后一列依赖前一列的新值（比如先算新 score，再用它更新 level），CASE WHEN 无法做到——所有 SET 子句右侧仍是并行求值的。
例如下面写法不会生效：
-- ❌ 错误示例：level 拿不到刚算出的新 score
SET score = CASE ... END,
level = CASE WHEN score > 90 THEN 'A' ... END -- 这里的 score 是旧值
- 真要实现链式依赖，得拆成两条
UPDATE，或用 CTE（PostgreSQL/SQL Server）或变量（MySQL） - 如果只是“看起来有关联”，实际仍基于原值（比如用
old_score和old_level共同决定新值），那一个CASE里写多个分支完全没问题 - 性能上，单条含
CASE的UPDATE比多条语句更优，因为只需一次表扫描
最容易被忽略的是：互换操作不可逆，没加 WHERE 就全表扫一遍，线上表务必先用 SELECT 验证条件范围，再套上 UPDATE。另外，某些数据库（如 MySQL）在事务中执行这类更新时，若涉及索引字段，可能触发额外锁行为——别只盯着语法，得看执行计划和锁等待。
