ifnull只接受两个参数，多参即报错；coalesce支持多参数、跨库兼容，且能暴露类型问题，更健壮安全。
IFNULL(expr1, expr2) 只能写两个参数，多一个就报错
MySQL 会直接拒绝执行 IFNULL(col, 'a', 'b') 这类调用，错误信息是 Incorrect parameter count in the call to native function 'IFNULL'。这不是语法警告，而是硬性限制——它本质就是个二元函数，没有“可选参数”或“扩展接口”的设计。
常见误操作包括：把 COALESCE(a, b, c) 习惯性改成 IFNULL(a, b, c)，结果连 SQL 都跑不起来；或者在迁移旧脚本时，没注意到嵌套的 IFNULL(a, IFNULL(b, c)) 其实已经隐含了逻辑复杂度。
- 只处理单字段兜底（如
IFNULL(price, 0)）时，IFNULL更紧凑 - 只要涉及三个及以上备选值，必须切到
COALESCE，别硬套嵌套 - 用 ORM 或代码拼接 SQL 时，动态构造
IFNULL很容易漏数参数，而COALESCE天然适配变长列表
COALESCE 是跨数据库的通用写法，IFNULL 在 PostgreSQL/SQL Server 里根本不存在
如果你写的 SQL 要跑在多个环境（比如开发用 SQLite、测试用 MySQL、生产用 PostgreSQL），COALESCE 是唯一安全的选择。PostgreSQL 不认 IFNULL，SQL Server 报 Invalid column name 'IFNULL'，Hive 里虽然有 IFNULL 别名，但参数规则和 MySQL 不完全一致。
更隐蔽的问题是：有些中间件（如某些 JDBC 连接池、BI 工具的 SQL 模板引擎）会做语法预检，遇到非标准函数直接拦截，根本不会发到 MySQL 执行。
- 写迁移脚本、数据同步任务、跨库视图时，强制用
COALESCE - 团队共用 SQL 片段库时，统一用
COALESCE可避免“本地能跑线上报错” -
COALESCE(NULL)合法，IFNULL(NULL)会报错 —— 单参数场景下COALESCE更健壮
类型隐式转换规则不同，COALESCE 更早暴露问题
COALESCE('2023-01-01', 42) 在 MySQL 中可能触发 Illegal mix of collations 或类型冲突错误，因为所有参数会被强制对齐为同一类型；而 IFNULL('2023-01-01', 42) 会把 42 静默转成字符串 '42'，表面成功，实际污染了字段语义。
这种静默转换在聚合计算或 JOIN 条件中尤其危险：比如 IFNULL(created_at, 0) 返回字符串 '0'，后续再和时间戳比较就全失效了。
- 混合数值与字符串时，
COALESCE的报错反而是好事，逼你显式 cast -
IFNULL的“宽容”常掩盖真实数据质量问题，比如你以为字段是 NULL，其实存的是空字符串'' - 在
ORDER BY中用COALESCE(col, 'zzz')控制 NULL 排序位置，比IFNULL更可靠，因为类型一致
WHERE 和 SELECT 中 NULL 判断逻辑必须前置确认
函数再熟也没用，如果字段压根不是 NULL，而是 ''、0 或 FALSE，IFNULL 和 COALESCE 都不会触发 fallback。这是最常被跳过的一步：直接写 COALESCE(phone, '无')，结果发现大量空字符串没被替换。
查清数据真实状态比选函数更重要。可以用这条语句快速验证：
SELECT COUNT(*) AS total,
COUNT(phone) AS non_null,
COUNT(NULLIF(TRIM(phone), '')) AS non_empty
FROM users;
只有当 non_null 时，才说明存在空字符串干扰；此时得先用 <code>NULLIF 清洗：COALESCE(NULLIF(TRIM(phone), ''), email, '无')。
真正卡住人的从来不是函数怎么写，而是 NULL 到底在哪、以什么形式存在。
