COALESCE支持多参数且符合ANSI SQL标准，IFNULL仅限MySQL、仅支持两参数；多值取非空时COALESCE更简洁安全，跨库迁移、可读性、维护性均优于IFNULL。
COALESCE 能接多个参数，IFNULL 只能写两个
这是最直接的分水岭。如果你要从 email、phone、wechat、'无联系方式' 四个值里取第一个非 NULL 的，IFNULL 根本没法直写——它只接受两个参数，硬要用就得嵌套：IFNULL(email, IFNULL(phone, IFNULL(wechat, '无联系方式')))。而 COALESCE 一行就搞定：COALESCE(email, phone, wechat, '无联系方式')。
嵌套写法不仅难读，还容易漏括号、错顺序；一旦字段增加或调整优先级，维护成本明显上升。
跨数据库迁移时 COALESCE 是唯一可靠选择
IFNULL 是 MySQL 独有的函数。PostgreSQL、SQL Server、Oracle、SQLite 都不认它，但都支持 COALESCE（它是 ANSI SQL 标准）。如果你的项目未来可能换数据库，或者团队同时维护多套环境（比如开发用 SQLite、上线用 MySQL），硬写 IFNULL 就是埋雷。
常见踩坑点：
- 本地测试用
IFNULL正常，CI 流水线跑 PostgreSQL 直接报错function ifnull does not exist - ORM 框架生成的 SQL 如果依赖方言，切换方言后查询逻辑意外失效
- 视图或存储过程里用了
IFNULL，导出到其他库时需人工逐行替换
两个参数时性能差异可忽略，别为这点微差牺牲可读性
有资料说 IFNULL 在双参数场景下“略微高效”，但实测在千万级表上，两者执行计划完全一致，耗时差在毫秒级以内。真正影响性能的是字段是否索引、是否触发全表扫描，而不是选了哪个空值函数。
更关键的是：用 COALESCE(a, b) 和 IFNULL(a, b) 在语义上完全等价，MySQL 内部优化器也按同样方式处理。所以与其纠结那点理论性能，不如统一用 COALESCE 降低认知负担。
顺带提醒：COALESCE 所有参数必须类型兼容，否则会隐式转换甚至报错。比如 COALESCE(created_at, 'N/A') 中，时间类型和字符串混用，MySQL 可能转成字符串再比对，结果不可控——这种类型混用问题，在 IFNULL 里一样存在，但多人协作时更容易被忽略。
WHERE 条件里用 COALESCE 要小心 NULL 传播
很多人想用 COALESCE 把 NULL 转成默认值后再比较，比如：WHERE COALESCE(status, 'draft') = 'active'。这看起来合理，但实际会漏掉所有 status IS NULL 的行——因为 COALESCE(NULL, 'draft') 返回 'draft'，永远不等于 'active'。
真正需要过滤 NULL 并补默认值的场景，应该拆开写：
-
WHERE status = 'active' OR status IS NULL（如果业务真允许 NULL 当 active） - 或者明确补值逻辑：
WHERE CASE WHEN status IS NULL THEN 'draft' ELSE status END = 'active'
直接在 WHERE 里套 COALESCE 容易让人误以为它能“修复”逻辑判断，其实它只是做值替换，不改变条件本身的语义边界。
