nullif是最轻量安全的防除零手段，但仅将分母为0转为null，须配合coalesce或case才能返回0或避免null；顺序必须为nullif(分母,0)，且需注意分母为null或含隐式字符时失效。
SQL分组统计时 NULLIF 怎么用才不报错
直接说结论：NULLIF 是最轻量、最安全的防除零手段，但它只在分母为 0 时返回 NULL，不会自动转成 0 或跳过计算——你得配合 COALESCE 或条件判断一起用，否则结果里会冒出一堆 NULL。
常见错误现象：写 SUM(a)/NULLIF(SUM(b), 0) 后发现某些分组结果是 NULL，但业务上希望显示 0 或空字符串；或者没加 COALESCE 就直接塞进报表工具，导致前端报“类型不匹配”。
-
NULLIF(expr1, expr2)的逻辑是“如果 expr1 == expr2，返回 NULL，否则返回 expr1”，所以NULLIF(SUM(b), 0)等价于“当分母为 0 时让整个分母变 NULL” - 它不能写成
NULLIF(0, SUM(b))——顺序反了就完全失效 - MySQL / PostgreSQL / SQL Server 都支持，但 SQLite 不支持（得改用
CASE WHEN）
分母为 0 时想返回 0 而不是 NULL，怎么接续处理
单纯靠 NULLIF 拦不住除零，只是把错误转化成 NULL；真正要“兜底”，必须再包一层 COALESCE 或 CASE。
使用场景：做转化率（paid_count / visit_count）、占比（error_cnt / total_cnt）这类指标时，某些分组可能完全没有访问或调用，分母天然为 0。
- 推荐写法：
COALESCE(SUM(a) * 1.0 / NULLIF(SUM(b), 0), 0)—— 乘1.0是为了防止整数除法截断（尤其在 PostgreSQL 和 SQL Server 中） - 如果需要保留小数位，别只写
0，改用0.0或CAST(0 AS DECIMAL(5,2)) - 避免嵌套过深：不要写
COALESCE(NULLIF(...), 0)，NULLIF返回的是分母，不是最终结果，放错位置会逻辑错乱
GROUP BY + 聚合函数里 NULLIF 的性能和兼容性注意点
NULLIF 本身几乎无开销，但它常被误用在不该聚合的地方，比如对单行字段直接 NULLIF(col, 0) 再除，结果和分组意图不符。
性能影响主要来自误用：如果在 WHERE 或 HAVING 里对聚合结果再套 NULLIF，可能让优化器放弃索引；而放在 SELECT 列表里是安全的。
- PostgreSQL 对
NULLIF(SUM(b), 0)有良好优化，和手写CASE WHEN SUM(b) = 0 THEN NULL ELSE SUM(b) END性能基本一致 - SQL Server 在旧版本（2012 以前）中，
NULLIF在某些窗口函数上下文中可能触发隐式转换警告，建议显式加CAST - 别在
GROUP BY子句里用NULLIF——它不是分组依据，也不该参与分组逻辑
替代方案对比：什么时候不该用 NULLIF
如果业务规则明确要求“分母为 0 时整个指标不可用”，那 NULLIF 加 COALESCE 反而是干扰项；这时候该用 CASE WHEN 显式控制逻辑分支。
容易踩的坑是：把 NULLIF 当万能开关，忽略了语义差异。比如统计“平均响应时间”，分母是请求数，分子是总耗时——若请求数为 0，返回 0 毫秒就完全失真。
- 需要区分“无数据”和“数据为 0”时，用
CASE WHEN SUM(b) = 0 THEN NULL ELSE SUM(a)/SUM(b) END更清晰 - 涉及多层嵌套聚合（如先按天算再按月汇总），
NULLIF必须放在最内层聚合后，不能等到外层再处理 - 如果分母可能为
NULL而非 0（比如上游 ETL 失败导致字段为空），NULLIF(SUM(b), 0)不生效，得先COALESCE(SUM(b), 0)再判零
最麻烦的其实是分母看起来是数字、实则带隐藏空格或不可见字符——这种时候 NULLIF 完全不起作用，得先清洗数据。别急着加函数，先 SELECT SUM(b), LENGTH(CAST(SUM(b) AS TEXT)) 看一眼实际值。
