NULLIF能防除零是因为当分母为0时返回NULL，而SQL中任何数除以NULL结果为NULL且不报错；正确写法是SUM(x)/NULLIF(SUM(y),0)，并常与COALESCE配合控制显示值。
分组汇总时 NULLIF 为什么能防除零？
因为 NULLIF(a, b) 在 a = b 时返回 NULL，而 SQL 中任何数除以 NULL 结果仍是 NULL，不会报错。聚合函数（如 SUM、COUNT）天然兼容 NULL —— 它们跳过 NULL 值计算，不会中断执行。
常见错误现象：division by zero 或数据库直接报错（如 PostgreSQL 的 ERROR: division by zero），尤其在用 SUM(x)/SUM(y) 做比率计算且某组 SUM(y) = 0 时必现。
-
NULLIF必须放在除法的**分母位置**，写成SUM(x) / NULLIF(SUM(y), 0)才有效；写反了（NULLIF(SUM(x), 0) / SUM(y)）没意义 - 不要试图用
CASE WHEN SUM(y) = 0 THEN NULL ELSE SUM(x)/SUM(y) END替代——逻辑等价但更冗长，且部分旧版 MySQL 对聚合结果做条件判断有隐式类型转换风险 -
NULLIF是标准 SQL 函数，PostgreSQL、SQL Server、SQLite、MySQL 8.0+ 都支持；但 SQLite 的NULLIF不接受非标量参数，需确保传入的是单值（即已在聚合后）
和 COALESCE 搭配控制最终显示值
分母为零时 NULLIF 返回 NULL，但业务常需要显示 0、'N/A' 或空字符串。这时必须用 COALESCE（或 IFNULL、ISNULL）包裹整个除法表达式，而不是只包分母。
使用场景：报表中“完成率 = 完成数 / 计划数”，计划数为 0 时显示 0.0% 而非 NULL。
- ✅ 正确：
COALESCE(SUM(done) * 100.0 / NULLIF(SUM(plan), 0), 0.0) - ❌ 错误：
SUM(done) * 100.0 / COALESCE(NULLIF(SUM(plan), 0), 0)—— 这会让分母变成 0，又回到除零 - 注意乘 100.0 而非 100：避免整数除法截断（如 PostgreSQL 中
5/2 = 2；加.0强制转为浮点）
GROUP BY 场景下 NULLIF 的实际写法
直接在 SELECT 中对聚合结果用 NULLIF 即可，无需改写 GROUP BY 或加子查询。它作用于每组聚合后的标量值，不是逐行处理。
性能影响几乎为零：不增加扫描或排序开销，只是对已算出的聚合值做一次判断。
- 示例（按部门统计人均销售额，规避部门总人数为 0）：
SELECT dept, SUM(sales) / NULLIF(COUNT(*), 0) AS avg_per_person FROM orders GROUP BY dept
- 如果分母是条件聚合（如
COUNT(CASE WHEN status='done' THEN 1 END)），同样适用：... / NULLIF(COUNT(CASE WHEN status='done' THEN 1 END), 0) - 别在 WHERE 或 HAVING 里用
NULLIF过滤分母为 0 的组——那会丢数据；NULLIF的价值正在于保留这些组，只让结果变NULL
容易被忽略的兼容性细节
MySQL 5.7 默认开启 sql_mode=STRICT_TRANS_TABLES，此时 1/0 会报错，但 1/NULLIF(0,0) 不会——因为 NULLIF(0,0) 先返回 NULL，再触发“任何数除以 NULL 得 NULL”的规则。这点在迁移旧逻辑时极易踩坑。
- PostgreSQL 对
NULLIF更严格：两个参数类型必须一致，NULLIF(COUNT(*), 0.0)会报错，得写NULLIF(COUNT(*), 0) - SQL Server 中
NULLIF等价于CASE WHEN a=b THEN NULL ELSE a END，所以分母写成NULLIF(SUM(y), 0)安全，但别写NULLIF(SUM(y), 0.0)（类型不匹配） - 所有数据库中，
NULLIF(x, x)永远返回NULL，所以确保你传进去的是确定值，而非可能为NULL的字段（NULLIF(col, 0)当col IS NULL时返回NULL，不是报错，但语义可能不符合预期）
真正要留心的不是 NULLIF 怎么写，而是想清楚：分母为零时，这个比率在业务上到底有没有意义。强行用 COALESCE 填 0 或 -1，有时比留 NULL 更误导人。
