SQL除零错误总在GROUP BY后爆发，因聚合后分母为0触发严格报错；NULLIF是跨库兼容的轻量防除零方案，将0转为NULL使运算继续，但需结合业务语义合理处理NULL结果。
SQL除零错误为什么总在GROUP BY后爆发
因为聚合函数如 SUM()、COUNT() 本身不报错，但一旦参与除法运算（比如计算转化率：SUM(paid) / COUNT(user_id)），而分母在某组中为0，数据库就直接抛出 division by zero 错误——尤其在 PostgreSQL、SQL Server 和较新版本的 MySQL 中默认严格拦截。这不是数据缺失问题，是计算逻辑没兜底。
NULLIF 是最轻量且跨库兼容的防除零方案
NULLIF(a, b) 的作用是：当 a = b 时返回 NULL，否则返回 a。把它套在除数位置，就能把“0”变成 NULL，而任何数除以 NULL 的结果也是 NULL，不会中断查询。
实际写法示例：
SELECT channel, SUM(conversions) AS conv, SUM(impressions) AS imp, ROUND(SUM(conversions) * 100.0 / NULLIF(SUM(impressions), 0), 2) AS ctr_pct FROM ads GROUP BY channel;
这里 NULLIF(SUM(impressions), 0) 确保只要某渠道的 impressions 总和为 0，除法就自然产出 NULL，而非报错。
- MySQL 5.7+、PostgreSQL、SQL Server、Oracle 都支持
NULLIF，语法一致 - 不要用
CASE WHEN SUM(x) = 0 THEN NULL ELSE SUM(x) END替代——写法冗长，且可能因重复计算影响可读性和优化器判断 -
NULLIF(x, 0)比NULLIF(x, 0.0)更安全：避免浮点数比较陷阱，整数场景优先用整数字面量
除零之外，NULLIF 还能预防其他隐性错误
它本质是「安全等值屏蔽」工具，适用所有需要“避开某个危险值再继续运算”的场景：
- 防止空字符串参与拼接导致意外前缀：
CONCAT(NULLIF(name, ''), ' (active)') - 规避时间差计算中起点=终点引发的负间隔：
EXTRACT(EPOCH FROM (end_time - NULLIF(start_time, end_time))) - 在窗口函数中控制分母基准：
AVG(sales) OVER (PARTITION BY region ORDER BY month ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) / NULLIF(COUNT(*) OVER (...), 0)
注意：NULLIF 只做等值判断，不能替代范围检查（如负数、NULL 本身）。如果分母可能是 NULL，需先用 COALESCE 或 CASE 处理，再套 NULLIF。
别忽略除零后业务语义的合理性
用 NULLIF 拦住报错只是第一步。真正容易被跳过的是后续处理：
- 前端展示时，
NULL值是否应显示为"—"、"N/A"或 0？这取决于指标定义（例如“无曝光下的点击率”本就无意义，填 0 会误导） - BI 工具中，
NULL可能被自动过滤或参与平均值计算，需确认聚合逻辑是否仍符合业务预期 - 某些旧版 SQLite 或极简嵌入式 SQL 引擎不支持
NULLIF，此时必须降级为CASE，且要测试分母为NULL的分支
防住崩溃只是底线；让 NULL 出现在对的地方，并被人正确理解，才是关键。
