NULL与0语义不等价：NULL表示未知或缺失，0表示已知且为零；混用会导致统计偏差、分组错误及逻辑误判，需按业务含义严格区分处理。
先看 NULL 和 0 在语义上是否等价
NULL 表示“未知”或“缺失”，0 表示“已知且为零”。比如订单表中 discount_amount 字段为 NULL，可能意味着折扣规则尚未配置；若为 0，则明确表示“不打折”。强行用 IFNULL(discount_amount, 0) 统计总折扣额，会把“未知”当成“无折扣”，导致低估真实优惠力度。
警惕聚合前补零引发的逻辑偏移
错误写法：SUM(IFNULL(price, 0)) —— 把原本 NULL 的价格（可能是未录入、待审核、无效记录）全算作 0 参与求和，虚增有效交易笔数，拉低平均单价。
正确做法：先过滤或标记缺失状态，再聚合。例如：
- 统计有效金额：SUM(price) —— 自动忽略 NULL，反映真实成交额
- 统计含缺失的行数：COUNT(*) - COUNT(price) —— 得出价格缺失条数
- 若业务真需补零，须配套说明：“本汇总含未定价条目，按零计入”
检查分组与条件筛选是否被补零干扰
在 GROUP BY 中对字段补零后分组，可能合并本应分离的语义类别。例如用户表中 age 为 NULL 表示年龄未填写，而 0 是合法但极罕见的值（如婴儿）。写成 GROUP BY IFNULL(age, 0) 会把所有未填年龄者与真实 age=0 的用户混为一组。
WHERE 条件中也易出错：WHERE IFNULL(status, 0) = 0 会同时匹配 status=0 和 status IS NULL 的行，但二者业务含义往往不同——前者是“已关闭”，后者是“状态未同步”。应拆解为：status = 0 OR status IS NULL，并明确注释每种分支的业务含义。
验证 JSON 或计算列中的隐式类型转换陷阱
对 JSON 字段使用 IFNULL(JSON_EXTRACT(data, '$.score'), 0) 返回的是数字 0，但若原始 JSON 中 score 是字符串 "null" 或缺失，JSON_EXTRACT 实际返回的是 SQL NULL，此时补零看似安全。可一旦该字段参与后续数值比较（如 > 5），而上游应用又误将结果当字符串处理，就可能因类型隐式转换导致判断失效。
更隐蔽的问题出现在计算列中：IFNULL(a / b, 0)。若 b 为 0，a / b 触发 #DIV/0! 错误，MySQL 直接返回 NULL，再被 IFNULL 捕获为 0 —— 表面无报错，实则掩盖了除零异常。应优先用 CASE WHEN b != 0 THEN a / b ELSE 0 END 显式控制。
