NULLIF(分母, 0)必须置于分母位置，因其仅在两参数相等时返回NULL，顺序错则失效；它将分母为0转为NULL，使除法结果为NULL而非报错，但需配合COALESCE或CASE处理NULL业务含义，避免前端异常。
直接用 NULLIF(分母, 0) 包住分母，是唯一轻量、跨库、不丢数据的防除零方案；但只加它不够，后续必须处理 NULL 的业务含义，否则报表或前端会出问题。
为什么 NULLIF(分母, 0) 必须写在分母位置
它不是“捕获错误”，而是提前把危险值替换成安全值：NULLIF 只在两个参数相等时返回 NULL，所以顺序和位置错一个就失效：
- ✅ 正确：
SUM(revenue) / NULLIF(SUM(cost), 0)—— 分母变NULL，整条除法退化为something / NULL → NULL - ❌ 错误：
NULLIF(SUM(revenue), 0) / SUM(cost)—— 分母仍是原始SUM(cost)，照样报division by zero - ❌ 错误：
NULLIF(SUM(revenue) / SUM(cost), 0)—— 除法先执行，错误已抛出，NULLIF根本没机会运行 - ❌ 错误：
NULLIF(0, SUM(cost))—— 永远返回0或NULL，分母没被替换
聚合后除法中 NULLIF 怎么用才不丢组
很多人想用 HAVING SUM(b) > 0 过滤掉分母为 0 的组，但这会直接剔除整行 —— 而业务上常需保留“0 成本”“0 曝光”的空组，仅让指标显示为 NULL 或占位符：
-
GROUP BY channel下，SUM(clicks) / NULLIF(SUM(impressions), 0)仍能返回每个渠道的记录，包括impressions = 0的渠道（结果为NULL） -
WHERE对聚合字段无效 ——SUM()是标量，不能出现在WHERE子句中 -
NULLIF天然适配聚合：输入是每组算完的单个数值，不是一列，所以对各组独立判断，不影响其他组
加了 NULLIF 后，NULL 结果怎么呈现才合理
NULLIF 只解决“不断查询”，不解决“怎么显示”。前端遇到 NULL 可能渲染为空白、触发类型错误，甚至被 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）
容易被忽略的类型与兼容性细节
NULLIF 看似简单，但类型不匹配或数据库差异会让它静默失效：
- 第二个参数必须是字面量
0，不是0.0—— 浮点比较可能因精度失败 - 如果分母列是字符串类型（比如存成
'0'），NULLIF(denominator, 0)因类型不匹配永远不生效，得写NULLIF(denominator, '0')或先转类型 - MySQL 5.7+、PostgreSQL、SQL Server、Oracle 都支持；SQLite 支持；BigQuery 不支持，得用
IF(denominator = 0, NULL, denominator) -
NULLIF(NULL, 0)返回NULL，符合预期；但NULLIF(0, NULL)返回0（因0 = NULL判定为 unknown）
