不能在UPDATE中动态拼接CASE分支，因SQL解析器要求CASE语法在编译期完整；可行方案是静态CASE配合程序侧拼接、映射表JOIN或CTE预计算。
不能直接在 UPDATE 中动态拼接 CASE 语句的分支——SQL 解析器要求 CASE 结构在执行前就语法完整，不支持运行时“追加 WHEN 分支”。 真正可行的是用静态 CASE + 动态生成逻辑（如程序侧拼接或视图/CTE 预计算），或者改用更灵活的映射表驱动方式。
为什么不能把 CASE 当作字符串拼接后 EXECUTE？
多数数据库（PostgreSQL、SQL Server、Oracle）不允许在普通 DML 里用 EXECUTE IMMEDIATE / EXEC() 执行含 UPDATE + CASE 的动态 SQL，除非写成存储过程；而 MySQL 的 PREPARE 在存储过程外受限更多。更关键的是，即使能执行，每次更新都拼 SQL 字符串会严重破坏查询计划缓存，且极易引入注入风险。
常见错误现象：ERROR: syntax error at or near "CASE"（PostgreSQL）、Incorrect syntax near 'CASE'（SQL Server），往往源于把未闭合的字符串当语句执行。
- CASE 必须在编译期确定所有
WHEN和ELSE分支，不能靠变量控制分支数量 - 参数差异：PostgreSQL 支持
CASE WHEN col IN (SELECT ...)，但子查询结果必须单列单值；SQL Server 的CASE不允许子查询返回多行 - 性能影响：嵌套过深的 CASE（如 50+ 个 WHEN）会导致优化器放弃统计估算，走全表扫描
用映射表 + LEFT JOIN 替代硬编码 CASE
这是最稳定、可维护性最强的批量差异更新方案：把“字段名 → 新值”的规则抽离到独立表，UPDATE 时通过 JOIN 应用规则。
假设要按地区批量更新 price：
UPDATE products p SET price = COALESCE(m.new_price, p.price) FROM price_mapping m WHERE p.region = m.region AND p.category = m.category;
说明：
-
price_mapping是普通表，可随时 INSERT/DELETE 规则，无需改 SQL -
COALESCE(m.new_price, p.price)确保没匹配上的行保持原值，避免被设为 NULL - 务必在
price_mapping(region, category)上建索引，否则 JOIN 变成嵌套循环，百万级数据会卡死
如果必须用 CASE，如何安全扩展分支？
接受“最大分支数固定”的前提，用预定义占位符 + 程序侧填充，而不是数据库内动态生成。
例如 Python 中构造语句：
rules = [("US", 19.99), ("JP", 24.99), ("DE", 21.50)]
when_clauses = " ".join([f"WHEN region = '{r[0]}' THEN {r[1]}" for r in rules])
sql = f"UPDATE products SET price = CASE {when_clauses} ELSE price END;"
关键点：
- 所有
{r[0]}必须经参数化处理（如 psycopg2 的%s占位符），绝不可用 f-string 直接插用户输入 - 分支上限建议 ≤ 20 —— 超过后优先考虑映射表方案
- MySQL 用户注意：
CASE表达式在 SET 子句中必须有ELSE，否则未匹配行会被设为 NULL
真正麻烦的不是写 CASE，而是当业务规则每天变、涉及几十个字段和上百种条件时，硬编码 CASE 会让 SQL 变成无法 review 的字符串拼接泥潭。映射表或配置化驱动才是长期可维护的解法。
