nullif(denominator, 0)能防除零错误，因其在分母为0时返回null，使除法结果为null而非报错；必须写成numerator / nullif(denominator, 0)，且参数顺序和位置不可错，否则无效。
直接结论：在 MySQL 中，NULLIF(denominator, 0) 必须作为分母参与除法运算，写成 numerator / NULLIF(denominator, 0) 才能真正防住除零报错；单独用或套错位置等于没用。
为什么 NULLIF(denominator, 0) 能拦住除零
因为 NULLIF(a, b) 在 a = b 时返回 NULL，否则返回 a。把它放在分母位置，就是把“除以 0”变成“除以 NULL”——而 MySQL（以及所有主流 SQL 引擎）规定：任何数除以 NULL 的结果是 NULL，不报错、不中断查询。
但注意：这**不是捕获错误**，而是让危险值在计算前就消失。所以顺序和位置不能错：
- ✅ 正确：
revenue / NULLIF(units_sold, 0) - ❌ 错误：
NULLIF(revenue, 0) / units_sold（改被除数，无效） - ❌ 错误：
NULLIF(0, units_sold)（参数反了，永远返回0或units_sold） - ❌ 错误：
NULLIF(revenue / units_sold, 0)（除法已先执行，错误早就抛出了）
MySQL 特有的坑：严格模式会让 NULLIF 失效
MySQL 默认可能开启 STRICT_TRANS_TABLES 或 STRICT_ALL_TABLES 模式，此时即使分母是 NULL，某些隐式转换场景仍可能触发 “Division by zero” 报错。
查当前模式：
SELECT @@sql_mode;
如果结果含 STRICT_*，稳妥做法是加一层兜底：
- 用
COALESCE提供默认值：COALESCE(revenue / NULLIF(units_sold, 0), 0) - 或改用兼容性更强的
CASE：CASE WHEN units_sold = 0 THEN NULL ELSE revenue / units_sold END - 不推荐临时关 strict mode，影响范围大且不可控
聚合后除法中怎么用才不出错
分母来自 SUM()、COUNT() 等聚合函数时，NULLIF 必须包裹整个聚合结果，而不是单个字段：
- ✅ 正确：
SUM(sales) / NULLIF(COUNT(*), 0) - ❌ 错误：
SUM(sales / NULLIF(quantity, 0))（先逐行除，quantity=0 时已崩）
还要注意类型陷阱：
- 别写
NULLIF(SUM(cost), 0.0)——如果SUM(cost)是DECIMAL，而0.0是DOUBLE，PostgreSQL 和部分 MySQL 配置下会因类型不匹配导致比较失败（始终不相等） - 统一用整数字面量
0，最安全 - 如果分母是字符串字段（如
'0'），得先TRIM()再CAST(... AS SIGNED)，否则NULLIF(col, 0)类型不匹配，恒为原值
得到 NULL 后，下游逻辑怎么接才不翻车
NULLIF 只负责不报错，不负责语义。应用层拿到 NULL 后，常见误操作有：
- 前端直接渲染
NULL→ 显示为空白或触发 JS 类型错误 - 报表里用
AVG()统计该列 →NULL被自动忽略，平均值偏高 - 写
WHERE result != 0过滤 → 漏掉所有NULL行（因为NULL != 0是UNKNOWN）
真正要做的，是明确业务规则：
- 需要标“不可算”？用
CASE WHEN units_sold = 0 THEN 'N/A' ELSE ... END - 允许填 0？外层套
COALESCE(..., 0)，不是包在NULLIF里 - 想保留原始
NULL但避免整数截断？分子乘100.0，别用100
最常被忽略的一点：除零转成 NULL 后，它和原始数据里的 NULL（比如未录入的分母）无法区分——如果你的业务要求“0 和 NULL 都算异常”，那就得提前清洗或叠加判断，NULLIF 本身做不到这点。
