coalesce不能直接用于insert/update/delete的values或set子句中自动补null，仅在select和表达式上下文中生效；dml中必须显式使用，如insert...select或update set配合参数。
COALESCE 不能直接用于 INSERT/UPDATE/DELETE 的 VALUES 或 SET 子句中做“自动补 NULL”——它只在 SELECT 和表达式上下文中生效，DML 语句里必须显式写出逻辑。
COALESCE 在 INSERT 中只能用在 SELECT 子查询里
你无法在 INSERT INTO t(col) VALUES (COALESCE(?, 'default')) 这种纯 VALUES 语法中安全使用 COALESCE，因为预编译参数（?）本身不参与 SQL 解析，COALESCE 无法对其求值。真正能用的地方是 INSERT ... SELECT：
- 从其他表导入数据时补空：
INSERT INTO orders (customer_id, amount) SELECT COALESCE(src.customer_id, 0), COALESCE(src.amount, 0) FROM staging_orders src; - 插入默认值组合：
INSERT INTO users (name, email) SELECT '匿名', COALESCE(@input_email, 'no-email@example.com');（注意：变量需提前 SET） - 别指望用
COALESCE绕过 NOT NULL 约束——如果列定义为NOT NULL，而你传入NULL且没用COALESCE包裹，语句会直接报错Column 'xxx' cannot be null
UPDATE 语句里 COALESCE 要配合 CASE 或子查询才可靠
UPDATE 的 SET 子句支持 COALESCE，但容易误用：
- 正确写法（安全补空）：
UPDATE products SET price = COALESCE(?, 99.99) WHERE id = ?;—— 这里?是客户端传入的可能为 NULL 的值，MySQL 在执行时计算COALESCE - 错误写法：
UPDATE products SET price = COALESCE(price, 99.99) WHERE id = 1;—— 这不会“修复历史 NULL”，只会把当前已为 NULL 的行设成 99.99，但对非 NULL 行无影响；想批量填充旧 NULL 值，得加条件：WHERE price IS NULL - 慎用多层嵌套：
COALESCE(a, b, c, 0)在 UPDATE 中性能无问题，但若a、b、c是函数或子查询，每次更新都会重新求值，可能拖慢大批量操作
COALESCE 与 DEFAULT、触发器、应用层的分工边界
很多人试图用 COALESCE 替代建表时的 DEFAULT，这是错的定位：
-
DEFAULT是 DDL 层约束，在 INSERT 缺失字段时自动生效；COALESCE是 DML 层表达式，只在你显式写出来时才起作用 - 触发器里可以用
COALESCE做兜底，但增加了维护成本；比如BEFORE INSERT中写NEW.price := COALESCE(NEW.price, 0);，比每次在应用里判断更集中，但也更难调试 - 最轻量的做法其实是应用层控制：入库前就用语言原生逻辑（如 PHP 的
$price ?? 0、Python 的or 0）处理好，避免把数据清洗逻辑塞进 SQL
真正容易被忽略的是：COALESCE 的参数类型必须兼容。比如 COALESCE(created_at, '1970-01-01') 在严格模式下会报错，因为 datetime 和 string 类型隐式转换失败——这种细节在 DML 场景下一旦出错，往往卡在整批更新中途，而不是报错提示你改写法。
