nullif是最轻量安全的防除零手段，它将分母为0转为null使除法不报错，但需配合coalesce或case指定业务含义；必须写成nullif(分母,0)且置于分母位置，否则失效。
直接用 NULLIF 包住分母，是处理聚合除零最稳、最简、跨库兼容的方式。 它不改逻辑、不增开销、不引入冗余计算，比 CASE WHEN 更安全，也比手动 COALESCE 套两层更清晰。关键不是“能不能防住”，而是“防住之后业务值怎么解释”——这点常被忽略。
为什么聚合后除零才报错，而单行不报？
因为聚合函数如 SUM()、COUNT() 本身跳过 NULL、不报错；但一旦参与除法（比如 SUM(paid) / SUM(clicks)），某组的 SUM(clicks) 算出来是 0，数据库就立刻中断执行。PostgreSQL、SQL Server 默认严格拦截，MySQL 8.0+ 也默认报错（除非 sql_mode 放宽）。这不是数据问题，是表达式没兜底。
-
SUM(clicks)是标量值，不是列——它已经汇总完成，不能再用WHERE clicks != 0过滤 -
HAVING SUM(clicks) > 0会直接丢弃整组，但业务可能需要展示“0点击、0转化”这类有意义的空组 - 用
CASE WHEN SUM(clicks) = 0 THEN NULL ELSE ... END虽然可行，但重复调用SUM(clicks)可能干扰优化器，且写法啰嗦
NULLIF(SUM(x), 0) 必须放在分母位置
NULLIF 的作用是“相等即转 NULL”，所以它必须套在除数上，而不是被除数或整个表达式外层。写反了等于白加。
- ✅ 正确：
SUM(revenue) / NULLIF(SUM(cost), 0) - ❌ 错误：
NULLIF(SUM(revenue), 0) / SUM(cost)—— 分母仍是SUM(cost)，没防住 - ❌ 错误：
NULLIF(SUM(revenue) / SUM(cost), 0)—— 除法先执行，已经报错了 - 整数场景下，用
NULLIF(SUM(x), 0)，别用NULLIF(SUM(x), 0.0)，避免浮点比较陷阱
NULLIF 防住报错后，结果怎么显示才合理？
NULLIF 只解决“不断查询”，不解决“怎么呈现”。业务上 NULL 往往不能直接扔给前端：转化率是 NULL，还是该标 “—”、“0%” 或 “N/A”？这取决于语义。
- 用
COALESCE(SUM(a) * 100.0 / NULLIF(SUM(b), 0), 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）
真正容易漏掉的，是分母本身可能是 NULL 的情况——比如 SUM(CASE WHEN status='done' THEN amount END) 在全组都不满足时返回 NULL，而 NULLIF(NULL, 0) 仍为 NULL，后续除法得 NULL，没问题；但如果业务要求把这种“全无数据”和“有数据但值为 0”区分开，就得先用 COALESCE(..., 0) 统一补零，再套 NULLIF。顺序不能错。
