优先用coalesce，因其是sql标准函数、支持多参数、跨数据库兼容；ifnull仅mysql特有、限两参数、类型处理宽松易致隐式转换错误且不兼容其他数据库。
COALESCE 和 IFNULL 不是“选哪个更好”，而是“能不能用、怎么用对”——关键看参数数量、类型兼容性和跨库需求。
COALESCE 支持多个参数，IFNULL 只能两个
这是最直接的分水岭。当你需要从 phone、email、address 里取第一个非 NULL 值时，COALESCE(phone, email, address, '暂无联系方式') 一行搞定；换成 IFNULL 就得嵌套：IFNULL(phone, IFNULL(email, IFNULL(address, '暂无联系方式')))，可读性差、易出错。
常见错误现象：写 IFNULL(phone, email, 'fallback') —— MySQL 会直接报错 Incorrect parameter count in the call to native function 'IFNULL'，因为它只认两个参数。
-
COALESCE至少要一个参数（COALESCE(NULL)合法，返回NULL） -
IFNULL必须且仅能有两个参数 - 如果逻辑只涉及单字段 fallback（如
IFNULL(price, 0)），两者效果等价，但COALESCE(price, 0)更通用
COALESCE 是 SQL 标准，IFNULL 是 MySQL 特有
如果你写的 SQL 要跑在 PostgreSQL、SQL Server 或 Hive 上，IFNULL 会直接报错或不识别；而 COALESCE 在所有主流 SQL 引擎里都可用。
使用场景：
- 写跨数据库兼容的迁移脚本或中间件 SQL —— 一律用
COALESCE - Hive 中
IFNULL和NVL实际是同一函数的别名，但COALESCE才是唯一支持多参数的选项 - PostgreSQL 没有
IFNULL，只有COALESCE和NULLIF
类型隐式转换规则不同，COALESCE 更严格
COALESCE 要求所有参数能隐式转为同一类型，否则报错，比如：COALESCE('2023-01-01', 42) 在 MySQL 中可能触发 Illegal mix of collations 或类型冲突；而 IFNULL('2023-01-01', 42) 会把整数 42 转成字符串再拼接，结果是 '42' —— 看似“成功”，实则埋了数据类型污染的坑。
性能影响：
-
COALESCE的类型推导发生在查询编译期，失败即报错，更早暴露问题 -
IFNULL的隐式转换发生在运行时，可能引发意外截断、精度丢失（如IFNULL(1.999, 2)返回2.0而不是2） - 高并发场景下，频繁的隐式转换会增加 CPU 开销
WHERE 和 ORDER BY 里 COALESCE 更安全
在 WHERE 条件中用 IFNULL(col, 'x') = 'x' 看似合理，但可能让索引失效（MySQL 对函数包裹的列无法使用索引）；而 COALESCE(col, 'x') = 'x' 同样失效 —— 这点两者没区别。真正容易被忽略的是 ORDER BY 行为：
MySQL 默认把 NULL 排在最前，ORDER BY COALESCE(col, 'zzz') ASC 能强制把 NULL 当作最大值排最后；但 IFNULL(col, 'zzz') 在排序中表现一致，不过一旦你换到 PostgreSQL，IFNULL 根本不存在 —— 所以统一用 COALESCE 避免环境切换时行为突变。
容易踩的坑：
- 在
UPDATE语句中写SET name = IFNULL(name, 'unknown')，如果name是NOT NULL字段，该语句不会报错但也没实际意义（因为name永远不为 NULL） -
COALESCE所有参数都会被计算（即使左边已非 NULL），存在副作用风险（比如含子查询或函数调用）
真正麻烦的从来不是语法记不住，而是某天把 MySQL 的 SQL 搬到 Hive 或 TiDB 上跑不通，或者线上突然因类型隐式转换导致金额字段变成字符串拼接 —— 这些都不是靠查文档能立刻反应过来的问题。
