CASE必须写在UPDATE的SET子句中用于动态赋值，不能用于WHERE条件过滤；多字段需独立CASE；务必显式写ELSE避免NULL覆盖；WHERE控制更新范围，CASE控制赋值逻辑。
UPDATE 中的 CASE 必须写在 SET 子句里，不能放在 WHERE 后面
很多人试图把 CASE 当成条件过滤器，写成 UPDATE ... WHERE CASE ... END = 1，这会报语法错误。SQL 标准里，CASE 在 UPDATE 中只允许出现在 SET 的右侧，用于动态计算字段值。
常见错误现象：ERROR: syntax error at or near "CASE" 或 column "xxx" does not exist（因误把 CASE 当列名引用）。
-
SET status = CASE WHEN order_amount > 1000 THEN 'VIP' ELSE 'NORMAL' END✅ 正确用法 -
WHERE CASE WHEN paid = true THEN 1 ELSE 0 END = 1❌ 错误；应改用WHERE paid = true - 多字段更新时，每个字段单独写一个
CASE，不能共用一个CASE块去赋多个值
嵌套 CASE 容易漏掉 ELSE，导致 NULL 覆盖原值
没写 ELSE 的 CASE 表达式，在条件都不匹配时返回 NULL。如果原字段不允许为 NULL，或你只是想“保持原值”，漏掉 ELSE 就会意外清空数据。
使用场景：批量修正状态码、分级打标、按规则补默认值。
- 安全写法是显式写
ELSE old_column_name，例如：SET category = CASE WHEN type = 'A' THEN 'alpha' WHEN type = 'B' THEN 'beta' ELSE category END - 若业务上确实允许 NULL，也建议加
ELSE NULL显式声明，避免后续维护者误判 - PostgreSQL 支持
ELSE CURRENT_VALUE（仅限某些版本），但兼容性差，不推荐依赖
WHERE 子句仍需保留，否则 CASE 会无差别执行全表
CASE 控制“设成什么值”，WHERE 控制“更新哪些行”。两者职责不同，不能互相替代。忽略 WHERE 可能导致整张表被误更新，且无法回滚（尤其没开事务时）。
性能影响：即使 CASE 逻辑复杂，只要 WHERE 能命中索引，数据库仍可快速定位行；反之，没 WHERE 就是全表扫描 + 全表更新，锁表时间长、IO 压力大。
- 正确组合：
UPDATE orders SET status = CASE WHEN shipped_date IS NOT NULL THEN 'shipped' ELSE 'pending' END WHERE created_at >= '2024-01-01' - 别用
CASE模拟过滤：比如想只更新未发货订单，不要写CASE WHEN shipped_date IS NULL THEN 'pending' ELSE status END，而应直接WHERE shipped_date IS NULL - MySQL 8.0+ 和 PostgreSQL 支持在
WHERE中用CASE，但语义混乱、难读，不建议
多个 WHEN 条件顺序重要，优先级从上到下匹配
CASE 是顺序求值：遇到第一个为 TRUE 的 WHEN 就返回对应结果，后续 WHEN 不再判断。条件顺序写错，会导致逻辑被覆盖。
典型陷阱：数值范围判断时，把宽泛条件写在前面，窄条件失效。例如：WHEN score > 0 THEN 'low' WHEN score > 80 THEN 'high' —— score = 95 也会进第一个分支。
- 正确顺序：从最具体到最宽泛，如
WHEN score >= 90 THEN 'A' WHEN score >= 80 THEN 'B' ELSE 'C' - 字符串比较注意大小写和空格：MySQL 默认不区分大小写，PostgreSQL 区分，
WHEN status = 'DONE'在 PG 里不会匹配'done' - NULL 判断必须用
IS NULL，不能用= NULL；WHEN col IS NULL THEN ...才有效
SELECT 验证 CASE 逻辑，尤其是涉及多层嵌套或边界值时。生产环境更新千万记得套 BEGIN; ... ROLLBACK; 测试，别信“就改三行”。 
