IFNULL仅处理SQL NULL，对空字符串等无效；需用NULLIF(bonus,'')先转再兜底；聚合函数后IFNULL仅适用于SUM/AVG等可能返回NULL的场景，COUNT(*)无需；类型不匹配会导致隐式转为0；多层fallback应优先用COALESCE。
IFNULL(expression, replacement) 的计算场景必须明确区分 NULL 和空字符串
IFNULL 只响应 SQL 层面的 NULL，对 ''（空字符串）、0、'0' 或 'false' 完全无感。很多“替换了却没生效”的问题，根源是数据里存的是空字符串而非 NULL。
验证方式很简单：
SELECT bonus, bonus IS NULL AS is_null, bonus = '' AS is_empty FROM employees LIMIT 5;
如果想同时处理 NULL 和空字符串，得先用 NULLIF() 转换：
-
IFNULL(NULLIF(bonus, ''), 0)—— 把空字符串先转成NULL，再统一兜底 - 但注意：这种写法在聚合后（如
SUM()）不适用，因为NULLIF是行级函数
在 SUM/AVG 等聚合函数后套 IFNULL 是常见且安全的做法
聚合函数本身不产生 NULL，但分组后某组无匹配记录时，SUM() 或 AVG() 会返回 NULL；而 COUNT(*) 永远不会是 NULL，所以没必要包 IFNULL。
典型正确写法：
SELECT dept_id, IFNULL(SUM(salary), 0) AS total_salary FROM employees GROUP BY dept_id;
错误写法示例（毫无意义）：
-
IFNULL(COUNT(*), 0)——COUNT(*)结果永远是整数 ≥ 0 -
IFNULL(AVG(score), 0.0)—— 看似合理，但语义上“平均分不存在”和“平均分为 0”完全不同，业务上可能误导
数值计算中 IFNULL 的类型隐式转换极易踩坑
IFNULL 的返回类型由两个参数共同决定，MySQL 会按规则做隐式提升。最危险的情况是：字段为 DECIMAL 或 INT，而你填了个字符串默认值。
例如：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
SELECT IFNULL(amount, '—') FROM transactions;
如果 amount 是 DECIMAL(10,2)，MySQL 会把 '—' 强转为 0.00，不是报错，也不是显示破折号，而是静默变成零值。
规避方法只有两个：
- 确保
replacement类型与expression一致：IFNULL(amount, 0.00) - 若真要显示文字，改用字符串上下文：
CONCAT(IFNULL(amount, 0.00), ' 元')，而不是混类型兜底
别用 IFNULL 做多层 fallback，优先选 COALESCE
IFNULL 只支持两个参数，硬要实现 “取 salary → 不行取 commission → 还不行取 base_pay” 就得嵌套：
IFNULL(salary, IFNULL(commission, base_pay))
这不仅可读性差，而且一旦某个中间字段类型不兼容（比如 commission 是 VARCHAR），整个表达式可能因类型推导失败而报错或截断。
更健壮的写法是直接用标准函数：
-
COALESCE(salary, commission, base_pay, 0)—— 明确、跨库、类型推导更稳定 - 尤其当查询未来可能迁移到 PostgreSQL 或 SQL Server 时，
COALESCE是唯一可靠选择
真正需要 IFNULL 的场景，其实就一种：MySQL 专属、逻辑极简、纯二选一兜底。复杂点的空值逻辑，别硬撑。
