COALESCE不能用于动态选择字段名，仅能动态处理字段值；它适用于UPDATE中按优先级取非NULL值赋值（如COALESCE(?, status)），但字段名必须预先确定，动态字段需靠应用层拼接或存储过程实现。
COALESCE 不能直接用于动态字段名，只能用于动态字段值
很多人误以为 COALESCE 可以像拼接 SQL 字符串那样决定“更新哪个字段”，其实它只作用于表达式求值结果——也就是字段的值，而非字段的名称。SQL 的 UPDATE 语句结构要求字段名必须在解析阶段就确定，无法靠运行时函数动态切换。
所以如果你的目标是「根据条件决定更新 status 还是 priority」，COALESCE 做不到；但如果是「更新 status，但值取自多个来源中的第一个非 NULL 值」，这就正好是它的本职工作。
用 COALESCE 实现“有则覆盖、无则保留”的字段赋值
这是 COALESCE 在 UPDATE 中最常见也最实用的场景：避免把空值写进数据库，同时不强制客户端传全量字段。
-
COALESCE(@new_status, status)表示：如果参数@new_status不为 NULL，就用它；否则保持原status值不变 - 多个备选时可链式写：
COALESCE(@input_priority, @fallback_priority, 0) - 注意：所有参数类型需兼容，否则可能触发隐式转换或报错，比如
COALESCE('high', 1)在 PostgreSQL 会失败，MySQL 可能转成字符串再比对 - 在 WHERE 子句里慎用
COALESCE，它可能导致索引失效（如WHERE COALESCE(updated_at, '1970-01-01') > ?）
示例：
UPDATE tasks
SET status = COALESCE(?, status),
priority = COALESCE(?, priority),
updated_at = NOW()
WHERE id = ?;
这里三个 ? 分别对应新 status、新 priority、任务 ID —— 传 NULL 就跳过更新该字段。
真要“动态字段”怎么办？得靠应用层或存储过程
如果业务逻辑确实需要根据某个 flag 决定更新 A 字段还是 B 字段（比如 type = 'urgent' 时只改 due_date，否则只改 assignee），就得跳出单条 UPDATE 的限制：
- 应用代码中判断条件，拼出不同字段列表的 UPDATE 语句（注意防 SQL 注入，用参数化）
- 在支持动态 SQL 的数据库里（如 PostgreSQL 的
EXECUTE+format()，SQL Server 的sp_executesql），用存储过程构造语句 - 用 CASE 配合固定字段名兜底：例如
SET status = CASE WHEN @update_flag = 'status' THEN @val ELSE status END，但这仍需提前列出所有可能字段，且语义上不如分治清晰
这种需求往往暴露了表设计问题：把行为差异很大的更新路径硬塞进同一张表，后期维护成本会上升。
容易被忽略的 NULL 处理细节
COALESCE 看似简单，但在 UPDATE 场景下几个边界容易翻车：
- 数据库默认 NULL 和空字符串
''是不同值，COALESCE('', 'default')返回''，不是'default' - 某些 ORM（如 SQLAlchemy）生成的参数绑定可能把 Python
None映射为 SQLNULL，但前端传空字符串时没做归一化，导致COALESCE没生效 - PostgreSQL 对
text和varchar的 NULL 判断严格，而 MySQL 在STRICT_TRANS_TABLES关闭时可能静默转空字符串 - 如果字段本身定义了
NOT NULL且无默认值，COALESCE(NULL, existing_col)是安全的；但如果existing_col当前就是 NULL，而你又没给默认值，就会报错
真正棘手的从来不是语法怎么写，而是你是否清楚每一层（前端输入 → 应用处理 → 参数绑定 → 数据库类型系统）里 NULL 是怎么流转和解释的。
