coalesce最合理用于字段允许null但业务需“视觉不为空”的兜底场景，如报表展示、接口返回、连接查询防空值传播；它仅影响查询结果，不修改存储，且必须按优先级从左到右排列参数，所有参数须类型兼容。
COALESCE 用在哪种场景下最合理
当数据库里某字段允许为 NULL，但业务逻辑需要它“看起来不为空”时，COALESCE 是最轻量、最标准的补救手段。它不是用来修复烂设计的，而是给已有 NULL 值一个安全兜底——比如报表展示、接口返回、连接查询时避免空值传播。
常见错误是把它当 IFNULL 或 NVL 的替代品硬套在所有地方，结果发现嵌套太深、可读性差，或者误以为它能改变存储值（它只影响查询结果）。
COALESCE 的参数顺序为什么不能乱
COALESCE 返回第一个非 NULL 的表达式，所以顺序直接决定默认值是否生效。写反了就等于没写。
- 正确：
COALESCE(user_name, '未知用户')—— 先查字段，空了才用默认值 - 错误：
COALESCE('未知用户', user_name)—— 字符串永远非空，user_name永远被忽略 - 多层兜底可以：
COALESCE(phone_work, phone_home, '暂无联系方式') - 注意类型兼容：所有参数必须能隐式转成同一类型，否则报错，比如
COALESCE(created_at, 'N/A')在 PostgreSQL 会失败（时间戳 vs 字符串）
和 CASE WHEN 比，什么时候该选 COALESCE
两者功能有重叠，但 COALESCE 更简洁、更语义明确，仅适用于“逐个判空取值”的线性逻辑；一旦需要条件判断（比如“大于100才用默认值”），就必须换 CASE WHEN。
- 用
COALESCE：字段为空就填默认值，不关心其他条件 - 别用
COALESCE：要根据字段值范围、字符串长度、关联表状态做判断 - 性能上差异极小，现代数据库对两者都做了优化，不必刻意替换
- 某些旧版 MySQL（COALESCE 的类型推导较弱，遇到混合类型时建议显式
CAST
在 UPDATE 或 INSERT 里用 COALESCE 要小心什么
COALESCE 可以用在 INSERT ... SELECT 或 UPDATE SET 中，但它只是计算表达式，不会自动跳过 NOT NULL 约束检查。
- 如果目标字段定义为
NOT NULL，而你写SET name = COALESCE(input_name, '')，那没问题；但写成COALESCE(input_name, NULL)就会违反约束 - 在
INSERT ... VALUES里不能直接用COALESCE，除非包装进子查询或 CTE - 触发器或默认值表达式里不支持
COALESCE（MySQL 不支持函数默认值，PostgreSQL 8.2+ 支持带函数的DEFAULT，但仅限于稳定函数）
真正容易被忽略的是：COALESCE 不会阻止原始数据写入 NULL，它只在读取或中间计算时起作用。想彻底规避 NULL，得靠表结构约束 + 应用层校验，而不是依赖这个函数。
