coalesce比ifnull更通用，因其支持多参数且跨数据库兼容；但要求所有参数可隐式转为同一类型，不处理空字符串，慎用于order by和聚合函数，并避免在参数中调用有副作用的函数。
COALESCE 为什么比 IFNULL 更通用？
因为 COALESCE 接收多个参数，从左到右返回第一个非 NULL 值；而 IFNULL 只能处理两个参数，且 MySQL 特有，跨数据库兼容性差。如果你要写可移植 SQL（比如将来切到 PostgreSQL），COALESCE 是更稳妥的选择。
常见错误是误以为 COALESCE 会自动类型转换——它不会。所有参数必须能隐式转为同一类型，否则报错 ERROR 1241 (21000): Operand should contain 1 column(s) 或类型冲突警告。
- 参数必须同一大类：数值型之间、字符串之间可混用（如
INT和DECIMAL），但不能把DATE和VARCHAR直接塞进同一个COALESCE - 如果字段是
TEXT，而你填了个空字符串''作替补，没问题；但填0就可能触发隐式转字符串，导致意外截断或警告 - MySQL 8.0+ 对混合字符集（如
utf8mb4和latin1）参数会报Illegal mix of collations
怎么安全地用 COALESCE 替换 NULL 为默认值？
最常见场景：查用户昵称，nickname 为空时显示“匿名”。直接写 COALESCE(nickname, '匿名') 即可，但要注意字段是否允许 NULL、字符集是否一致。
如果字段本身是 NOT NULL 但值为 ''（空字符串），COALESCE 不会捕获它——它只管 NULL。这时得组合 CASE：
SELECT
CASE
WHEN nickname IS NULL OR TRIM(nickname) = '' THEN '匿名'
ELSE nickname
END AS display_name
FROM users;
- 别依赖
COALESCE(col, '')来“清空 NULL 感觉”，它只是替换，不改变原始数据语义 - 在
ORDER BY中用COALESCE要小心：比如ORDER BY COALESCE(created_at, '1970-01-01')，若created_at是DATETIME，MySQL 会把字符串强转为日期，可能出错或降级为 0000-00-00 - 性能上无明显开销，但嵌套太深（如
COALESCE(COALESCE(a,b), COALESCE(c,d))）可读性差，不如拆成CASE
在 JOIN 和聚合查询里 COALESCE 怎么避坑？
LEFT JOIN 后某字段可能全为 NULL，比如查订单 + 用户信息，用户被删了，users.name 全是 NULL。这时 COALESCE(users.name, '已注销') 是合理做法。
但在 GROUP BY 或 AVG() 等聚合中，COALESCE 位置很关键：
- 写成
AVG(COALESCE(price, 0))：把NULL当 0 算入平均值 → 结果偏低 - 写成
AVG(price)（默认忽略NULL）更符合统计本意；真要补零，应先明确业务逻辑是否允许“无价格=免费” - 在
GROUP_CONCAT(COALESCE(tag_name, '未分类'))中，若tag_name为NULL，GROUP_CONCAT会跳过该行——除非你加SEPARATOR并确保所有项非NULL
COALESCE 和 NULLIF、IS NULL 判定怎么配合？
NULLIF(a, b) 返回 NULL 当 a = b，否则返回 a。它常和 COALESCE 连用，比如过滤掉无效的占位值：
SELECT COALESCE(NULLIF(phone, ''), '未提供') FROM contacts;
这比 CASE WHEN phone = '' THEN '未提供' ELSE phone END 更紧凑。但注意：
-
NULLIF比较是严格相等，不忽略前后空格；如需容错，先TRIM(phone) -
COALESCE(IS NULL col, 'yes', 'no')是错的：IS NULL返回布尔值（1或0），不是NULL，所以永远走不到第三个参数 - 真正需要判断并分支时，优先用
CASE WHEN col IS NULL THEN ... ELSE ... END，语义清晰，也避免COALESCE的类型推导干扰
真正容易被忽略的是：COALESCE 的每个参数都会被求值，哪怕前面已经选出非 NULL 值。所以别在里面放子查询或函数调用（如 COALESCE(col, SLEEP(1))），否则可能引发意外延迟或副作用。
