NULLIF(分母, 0)是防除零最稳最简跨库方案，但需同步处理NULL语义和整数截断；聚合后除法报错因SUM等跳过NULL但除法遇0即中断，且HAVING或WHERE无法过滤聚合结果中的0。
直接用 NULLIF(分母, 0) 包住分母，是防除零最稳、最简、跨库兼容的方式；但光加它还不够，必须同步处理结果为 NULL 的语义和整数截断问题。
为什么聚合后除法才报错，单行不报？
因为聚合函数如 SUM()、COUNT() 本身跳过 NULL、不报错；但一旦结果参与除法（比如 SUM(paid) / SUM(clicks)），某组的 SUM(clicks) 算出来是 0，数据库就立刻中断执行。PostgreSQL 和 SQL Server 默认严格拦截，MySQL 8.0+ 也默认报错（除非 sql_mode 放宽）。这不是数据问题，是表达式没兜底。
常见错误现象：Msg 8134, Level 16, State 1 或 division by zero 直接崩查询，连一行结果都不返回。
-
HAVING SUM(clicks) > 0会直接丢弃整组，但业务可能需要展示“0点击、0转化”这类有意义的空组 -
WHERE clicks != 0对聚合结果无效——SUM(clicks)是标量值，不是列，不能在WHERE中过滤
NULLIF 必须写在分母位置，顺序和字面量都不能错
NULLIF 的作用是“相等即转 NULL”，所以它必须套在除数上，而不是被除数或整个表达式外层。写反了等于白加。
✅ 正确：SUM(revenue) / NULLIF(SUM(cost), 0)
❌ 错误：NULLIF(SUM(revenue), 0) / SUM(cost) —— 分母仍是 SUM(cost)，没防住
❌ 错误：NULLIF(SUM(revenue) / SUM(cost), 0) —— 除法先执行，已经报错了
关键细节：
- 第二个参数必须是字面量
0，不是0.0（避免浮点比较陷阱） -
NULLIF(NULL, 0)返回NULL，符合预期；但NULLIF(0, NULL)返回0（因0 = NULL判定为 unknown） - 如果分母本身可能为
NULL（如SUM(CASE WHEN status='done' THEN amount END)全不满足时返回NULL），NULLIF不会干涉它，结果仍是NULL—— 这属于正常行为，不是 bug
加了 NULLIF 后，结果怎么显示才合理？
NULLIF 只解决“不断查询”，不解决“怎么呈现”。业务上 NULL 往往不能直接扔给前端：转化率是 NULL，还是该标 “—”、“0%” 或“N/A”？这取决于语义。
推荐组合写法：
- 表示“无分母即为 0%”：
COALESCE(SUM(a) * 100.0 / NULLIF(SUM(b), 0), 0.0) - 表示“异常态需单独标记”：
COALESCE(SUM(a) * 100.0 / NULLIF(SUM(b), 0), -1) - 千万别写成：
SUM(a) * 100.0 / COALESCE(NULLIF(SUM(b), 0), 0)—— 外层COALESCE把NULL换回0，又回到除零
还要记得乘 100.0 而非 100：防止整数除法截断（例如 PostgreSQL 中 5/2 = 2）。
不同数据库的兼容性与替代方案
NULLIF 是 SQL:2003 标准函数，PostgreSQL、SQL Server、Oracle、Snowflake、Trino、SQLite 都支持；MySQL 从 5.7+ 支持。但 BigQuery 不支持，得用 IF(den = 0, NULL, den)。
浮点分母要小心：NULLIF(x, 0.0) 可能因精度问题失效，稳妥做法是转为 DECIMAL 或配合 ABS(x) 判断。
真正容易漏掉的点：
- 分母是表达式（如
SUM(CASE ...)）时，它可能为NULL或0，两种情况都要覆盖 - 视图定义中加了
NULLIF，但前端没处理NULL，导致报表空白或格式错乱 - 以为加了
NULLIF就万事大吉，忘了类型提升和业务含义解释
