NULLIF(分母, 0)是最轻量且跨库兼容的防除零方案，它将分母为0时转为NULL，使除法结果为NULL而非报错；必须置于分母位置，如SUM(a)/NULLIF(SUM(b),0)，放错则失效。
直接说结论：在复杂关联查询中，除数为零不会导致“系统宕机”，但会中断当前SQL执行并抛出错误（如 PostgreSQL 的 division by zero、SQL Server 的 Msg 8134），使整个结果集丢失。真正有效的规避方式不是关警告或调配置，而是把分母的“0”提前转成 NULL，再让除法自然产出 NULL——NULLIF(分母, 0) 是最轻量且跨库可用的写法，但必须放在分母位置，且不能替代业务语义判断。
为什么 NULLIF(分母, 0) 必须写在分母位置？
因为 NULLIF 本身不执行除法，它只做“相等即 NULL”的替换。只有当它作为除法的右操作数（即分母）时，才能让整条表达式因遇到 NULL 而跳过计算、返回 NULL。
- ✅ 正确：
SUM(revenue) / NULLIF(SUM(cost), 0)—— 分母为 0 时，NULLIF返回NULL，整条除法结果为NULL - ❌ 错误：
NULLIF(SUM(revenue) / SUM(cost), 0)—— 除法先执行，已报错，NULLIF根本没机会运行 - ❌ 错误：
NULLIF(0, SUM(cost))—— 顺序反了，永远返回0或NULL，起不到保护作用
关联查询里分母是聚合结果，NULLIF 还够用吗？
够用，但有局限：它只处理值等于 0 的情况，对 NULL 分母无感（NULLIF(NULL, 0) 返回 NULL，除法仍得 NULL），而你可能需要区分“无数据”和“分母为 0”。
- 如果只要“不报错”，
NULLIF(SUM(cost), 0)已足够 - 如果要打标（比如把分母为 0 的组标为
'zero_denom'，NULL的标为'no_data'），必须用CASE显式分支 - 示例（PostgreSQL/MySQL 8.0+）：
CASE WHEN SUM(cost) IS NULL THEN 'no_data' WHEN SUM(cost) = 0 THEN 'zero_denom' ELSE ROUND(SUM(revenue)/SUM(cost), 2) END
MySQL 严格模式下 NULLIF 为什么还会报错？
因为 MySQL 在 sql_mode 含 STRICT_TRANS_TABLES 或 STRICT_ALL_TABLES 时，会对除法运算本身做更早的合法性校验，哪怕分母已是 NULLIF(...)，也可能在执行前就拒绝。
- 查当前模式：
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 表示默认值？还是该由上游过滤掉无效分组？一旦关联层级变深、聚合嵌套增多，分母的语义就容易模糊，这时候靠函数堆砌不如靠 CASE 把每种状态写死。
