nullif本身不规避报错，而是将分母为0提前转为null，使除法结果为null而非报错；必须写成numerator / nullif(denominator, 0)，且0为字面量整数，nullif必须置于分母位置。
直接结论：NULLIF本身不“规避报错”，它靠把分母提前变成 NULL，让除法自然返回 NULL 而非触发 division by zero 错误；关键必须写成 numerator / NULLIF(denominator, 0)，且 0 必须是字面量整数。
为什么 NULLIF(denominator, 0) 必须放在分母位置
数据库执行顺序是自左向右、先算子表达式再算运算符。除法 / 是二元操作符，它的右操作数（即分母）必须在除法执行前就准备好——NULLIF 只有在这个位置才能抢在除法出错前把危险值干掉。
- ✅ 正确：
SUM(revenue) / NULLIF(SUM(cost), 0)→ 若SUM(cost)为 0，NULLIF立即返回NULL，整条表达式变为SUM(revenue) / NULL→ 结果为NULL - ❌ 错误：
NULLIF(SUM(revenue), 0) / SUM(cost)→ 分母仍是原始SUM(cost)，若为 0，除法立刻报错 - ❌ 错误：
NULLIF(SUM(revenue) / SUM(cost), 0)→ 除法已先执行，错误抛出后NULLIF根本没机会运行 - ❌ 错误：
NULLIF(0, SUM(cost))→ 永远返回0或NULL，分母未被替换，防护失效
聚合场景下 NULLIF 怎么用才不丢组、不误判
在 GROUP BY 查询中，NULLIF 的输入是每组聚合后的标量值（如 SUM(impressions)），不是整列数据。这意味着它对每组独立判断，不会影响其他组，也不会导致整行被过滤掉——这点比 HAVING SUM(impressions) > 0 更符合“保留空组”的业务需求。
-
NULLIF(SUM(impressions), 0)对SUM(impressions) = 0的组返回NULL，该组记录仍保留在结果中，指标显示为NULL -
NULLIF(NULL, 0)返回NULL，语义一致（无数据 → 无分母），无需额外处理 - 但
NULLIF(0.0, 0)在多数库中仍返回NULL，而NULLIF(0.0001, 0)不会变——所以若分母可能含浮点计算，别依赖0.0，改用CAST(... AS DECIMAL)或范围判断 - 注意：如果
SUM(cost)因正负抵消得 0（如 -100 + 100），NULLIF也会把它转成NULL，这属于业务逻辑歧义，需结合上下文判断是否真要拦截
加了 NULLIF 之后，NULL 怎么呈现才不翻车
NULLIF 只解决“不断查询”，不解决“怎么显示”。前端或报表遇到 NULL 可能渲染为空白、触发 JS 类型错误，或被 AVG() 统计时忽略，造成偏差。
- 想默认填 0：
COALESCE(amount / NULLIF(quantity, 0), 0)—— 注意COALESCE必须包在外层，不是NULLIF(COALESCE(...), 0) - 想标“N/A”：
CASE WHEN quantity = 0 THEN 'N/A' ELSE CAST(amount * 100.0 / NULLIF(quantity, 0) AS DECIMAL(5,2)) END - 千万别写：
amount / COALESCE(NULLIF(quantity, 0), 0)—— 外层又把NULL换回0，立刻复现除零 - 记得用
100.0而非100：避免整数除法截断（例如 PostgreSQL 中3/5 = 0，再乘100还是0）
MySQL 严格模式下 NULLIF 还管用吗
MySQL 在 sql_mode 含 STRICT_TRANS_TABLES 或 STRICT_ALL_TABLES 时，会对除法做更早的合法性校验，即使分母已是 NULLIF(..., 0)，也可能报 Division by zero。
- 先查当前模式：
SELECT @@sql_mode - 稳妥兜底写法：
COALESCE(SUM(revenue) / NULLIF(SUM(cost), 0), 0) - 或显式分支：
CASE WHEN COALESCE(SUM(cost), 0) = 0 THEN 0 ELSE SUM(revenue)/SUM(cost) END - 不推荐临时改
sql_mode：影响范围大，上线易遗漏，且不可控
真正容易被忽略的，从来不是怎么写 NULLIF，而是想清楚：这个除法在业务里到底该返回什么——NULL 表示跳过？0 表示默认值？还是该由上游过滤掉无意义的分母？
