NULLIF(分母, 0)是聚合后除法防崩的必要轻量兜底方案，必须严格套在分母位置（如SUM(revenue)/NULLIF(SUM(cost),0)），否则无法阻止division by zero中断查询。
NULLIF 是聚合后除法不崩的唯一轻量兜底方案，不是“可选优化”，而是防止整条查询直接中断的必要操作。
聚合后除法报错根本停不下来
因为 SUM、COUNT 这些函数自己不报错，但它们的结果一旦参与除法（比如 SUM(revenue) / SUM(cost)），只要某组的分母算出来是 0，PostgreSQL/SQL Server/Oracle 就立刻抛 division by zero；MySQL 8.0+ 默认也报错（除非 sql_mode 放宽）。这不是数据问题，是表达式没做安全包裹——错误发生在除法执行瞬间，连结果集第一行都吐不出来。
-
HAVING SUM(cost) > 0会直接丢掉整组，但业务常需要保留“成本为 0”的渠道或时段，仅让指标显示为 NULL 或占位符 -
WHERE cost != 0对聚合结果无效：WHERE 只能过滤原始行，不能作用于SUM(cost)这种标量值 - 想用
CASE WHEN SUM(cost) = 0 THEN NULL ELSE ... END？它得先算两次SUM(cost)，性能差，还容易漏写ELSE分支导致意外报错
NULLIF(分母, 0) 必须套在分母上，顺序和位置错一个就失效
它的作用不是“捕获错误”，而是提前把危险值替换成安全值：NULLIF 只在两参数相等时返回 NULL，所以必须确保第二个参数是字面量 0，且整个函数只包住分母：
- ✅ 正确：
SUM(revenue) / NULLIF(SUM(cost), 0)—— 分母变NULL，整条除法退化为something / NULL → NULL - ❌ 错误：
NULLIF(SUM(revenue), 0) / SUM(cost)—— 分母仍是SUM(cost)，照样崩 - ❌ 错误：
NULLIF(SUM(revenue) / SUM(cost), 0)—— 除法先执行，错误已抛出，NULLIF根本没机会运行 - ❌ 错误：
NULLIF(0, SUM(cost))—— 永远返回0或NULL，分母没被替换
加了 NULLIF 后，NULL 怎么呈现才不翻车
NULLIF 只解决“不断查询”，不解决“怎么显示”。前端看到 NULL 可能渲染为空白、触发 JS 类型错误，甚至被 AVG() 忽略导致统计偏差：
- 想标“无数据”：
CASE WHEN SUM(impressions) = 0 THEN 'N/A' ELSE CAST(SUM(clicks) * 100.0 / NULLIF(SUM(impressions), 0) AS DECIMAL(5,2)) END - 想默认填 0：
COALESCE(SUM(clicks) * 100.0 / NULLIF(SUM(impressions), 0), 0.0)—— 注意是外层COALESCE，不是包在NULLIF里 - 千万别写：
SUM(clicks) * 100.0 / COALESCE(NULLIF(SUM(impressions), 0), 0)—— 外层又把NULL换回0，立刻复现除零 - 记得乘
100.0而非100：避免整数除法截断（例如 PostgreSQL 中3 / 5 = 0，再乘100还是0）
浮点分母和跨库兼容性最容易被忽略
如果分母是 DOUBLE 或 FLOAT 类型（比如 SUM(revenue_usd)），直接写 NULLIF(x, 0.0) 可能因精度问题失效——0.0000001 = 0.0 判定为 false，NULLIF 不触发。稳妥做法是先转精度类型：NULLIF(CAST(x AS DECIMAL), 0)。
- BigQuery 不支持
NULLIF，得用IF(x = 0, NULL, x) -
NULLIF(NULL, 0)返回NULL，符合预期；但NULLIF(0, NULL)返回0（因为0 = NULL是UNKNOWN，不满足相等条件） - 第二个参数必须是字面量
0，不能是变量或表达式，否则语义就变了
