先说结论：在复杂关联查询中，除数为零并不会真的让系统“宕机”，但它会中断当前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 还够用吗？
够用，但要注意它的局限。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 把每种状态写死，一劳永逸。
