聚合后除法才报错是因为sum()等聚合函数本身跳过null不报错，但聚合结果为0时参与除法（如sum(paid)/sum(clicks)）会触发数据库严格拦截；必须用nullif(sum(分母), 0)置于分母位置防错，并配合coalesce或case处理null语义，避免整数截断和业务误导。
为什么聚合后除法才报错，单行不报？
因为聚合函数如 SUM()、COUNT() 本身跳过 NULL、不报错；但一旦结果参与除法（比如 SUM(paid) / SUM(clicks)），某组的 SUM(clicks) 算出来是 0，数据库就立刻中断执行。PostgreSQL 和 SQL Server 默认严格拦截，MySQL 8.0+ 也默认报错（除非 sql_mode 放宽）。这不是数据问题，是表达式没兜底。
必须把 NULLIF() 套在分母上，顺序不能错NULLIF() 的作用是“相等即转 NULL”，所以它必须套在除数上，而不是被除数或整个表达式外层。写反了等于白加。
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）。
用 NULLIF 后，NULL 结果怎么处理才不误导业务？NULLIF 只解决“不断查询”，不解决“怎么显示”。报表里一堆 NULL，前端可能渲染为空白、触发类型错误，甚至被 AVG() 统计时忽略，导致偏差。
- 想标“无数据”：
CASE WHEN SUM(clicks) = 0 THEN 'N/A' ELSE CAST(SUM(conversions) * 100.0 / NULLIF(SUM(clicks), 0) AS DECIMAL(5,2)) END
- 想默认填
0.0：COALESCE(SUM(conversions) * 100.0 / NULLIF(SUM(clicks), 0), 0.0)
- 千万别写：
SUM(conversions) / COALESCE(NULLIF(SUM(clicks), 0), 0) —— 外层把 NULL 换回 0，又回到除零
- 还要记得乘
100.0 而非 100，否则整数除法会截断（比如 PostgreSQL 中 3/5 = 0，再乘 100 还是 0）
聚合场景下，NULLIF 为什么天然适配 GROUP BY？NULLIF(SUM(clicks), 0) 的输入已经是每组聚合后的单个数值（标量），不是一列数据。它对每个分组独立判断，不影响其他组，也不丢数据——哪怕某渠道 SUM(clicks) 是 0，该渠道记录仍保留在结果里。而用 HAVING SUM(clicks) > 0 会直接剔除整组，业务上往往不可接受。
CASE WHEN SUM(clicks) = 0 THEN 'N/A' ELSE CAST(SUM(conversions) * 100.0 / NULLIF(SUM(clicks), 0) AS DECIMAL(5,2)) END 0.0：COALESCE(SUM(conversions) * 100.0 / NULLIF(SUM(clicks), 0), 0.0) SUM(conversions) / COALESCE(NULLIF(SUM(clicks), 0), 0) —— 外层把 NULL 换回 0，又回到除零 100.0 而非 100，否则整数除法会截断（比如 PostgreSQL 中 3/5 = 0，再乘 100 还是 0）NULLIF 为什么天然适配 GROUP BY？NULLIF(SUM(clicks), 0) 的输入已经是每组聚合后的单个数值（标量），不是一列数据。它对每个分组独立判断，不影响其他组，也不丢数据——哪怕某渠道 SUM(clicks) 是 0，该渠道记录仍保留在结果里。而用 HAVING SUM(clicks) > 0 会直接剔除整组，业务上往往不可接受。
真正容易被跳过的，是分母为 0 时是否真该返回 NULL：比如“0 曝光下的点击率”本就无意义，填 0 会误导；但“0 成本下的利润率”可能需按业务规则特殊解释。
