COALESCE(numerator / NULLIF(denominator, 0), default_value)是正确写法，因NULLIF仅将分母为0转为NULL使除法安全返回NULL，而COALESCE在外层兜底解决NULL的业务呈现问题；NULLIF必须置于分母位置且第二参数为字面量0。
直接结论：用 COALESCE(numerator / NULLIF(denominator, 0), default_value)，且 NULLIF 必须包在分母位置、第二个参数必须是字面量 0。
为什么不能只写 NULLIF(denominator, 0)
NULLIF 本身不“处理错误”，它只是把 denominator = 0 的情况转成 NULL，让除法变成 numerator / NULL → 结果为 NULL。但业务上往往需要显示 0 或 'N/A'，而不是任由 NULL 传到前端引发空指针或空白渲染。所以单靠 NULLIF 只解决了“不断查询”，没解决“怎么呈现”。
- 写成
NULLIF(denominator, 0)后不加COALESCE或CASE，下游应用可能崩溃或漏统计（比如AVG()会跳过NULL） - 如果误写成
COALESCE(NULLIF(denominator, 0), 0)再做除法，等于又把分母变回0，立刻复现除零 -
NULLIF对浮点字段（如DECIMAL(10,2)）仍认0，但若字段存的是0.0001，它不会触发，得结合业务判断是否要先ROUND()或用范围判断
COALESCE 必须套在外层，不是里面
正确结构是：先让除法安全返回 NULL，再用 COALESCE 统一兜底。顺序错了就前功尽弃。
- ✅ 正确：
COALESCE(SUM(revenue) * 100.0 / NULLIF(SUM(cost), 0), 0.0) - ❌ 错误：
SUM(revenue) * 100.0 / COALESCE(NULLIF(SUM(cost), 0), 0)—— 外层又塞回0，除零照报 - ❌ 错误：
COALESCE(NULLIF(SUM(revenue) / SUM(cost), 0), 0)—— 除法已先执行，NULLIF根本没机会运行 - 注意乘
100.0而非100：避免整数除法截断（如 PostgreSQL 中3/5 = 0，再 ×100 还是0）
聚合场景下常见踩坑点
在 GROUP BY 查询里，分母常是 SUM()、COUNT() 等聚合结果，这时 NULLIF 的输入是标量值，不是整列——这是它比 HAVING 更适合保留空组的原因。
-
SELECT channel, SUM(clicks) / NULLIF(SUM(impressions), 0) FROM log GROUP BY channel：impressions = 0 的渠道仍会出一行，结果为NULL - 别用
HAVING SUM(impressions) > 0过滤——这会直接丢掉 impressions = 0 的渠道，业务上可能需保留“零曝光但有点击”的异常数据 -
WHERE不能用聚合字段，所以想提前过滤只能靠子查询或 CTE，但不如NULLIF直接、轻量 - 如果
SUM(cost)因正负抵消得0（如-100 + 100），NULLIF也会转NULL，这不是 bug，而是业务逻辑歧义，得看是否真要拦截这种“净零”场景
跨数据库兼容性与类型细节
NULLIF 是 SQL:2003 标准函数，PostgreSQL、SQL Server、Oracle、Snowflake 都支持；MySQL 5.7+ 支持；SQLite 支持。但 BigQuery 不支持，得换 IF(denominator = 0, NULL, denominator)。
- 第二个参数必须是字面量
0，不是0.0或列名——类型不一致时（如NULLIF(decimal_col, 0.0)），某些库（如 PostgreSQL）可能不匹配，导致防护失效 -
NULLIF(NULL, 0)返回NULL，行为稳定；但NULLIF(0, NULL)返回0（因为0 = NULL判定为 unknown，不满足相等条件） - 如果分母来自表达式（如
COALESCE(col, 0)），确保它没被提前求值为0再套NULLIF，否则等于白加
真正容易被忽略的，是 NULLIF 把问题从“报错”转成了“返回 NULL”，而后续所有环节——BI 工具取值逻辑、前端 JS 的 ?.value、报表导出的空单元格处理——都得适配这个 NULL，否则就是换种方式翻车。
