NULLIF(denominator, 0) 将除数为0转为NULL，使除法结果为NULL而非报错，因SQL标准规定任何数除以NULL返回NULL；需配合COALESCE或CASE处理业务语义，注意NULL输入、类型转换及WHERE中NULL逻辑。
直接用 NULLIF 把除数为 0 的情况转成 NULL，再配合 COALESCE 或业务逻辑兜底，就能安全绕过除以零错误。
为什么 NULLIF 能拦住除以零？
NULLIF(a, b) 的行为是：当 a = b 时返回 NULL，否则返回 a。把它用在除数位置，比如 NULLIF(denominator, 0)，就能把所有值为 0 的除数变成 NULL。
而任何数除以 NULL 的结果也是 NULL（不是报错），SQL 引擎会安静跳过——这是标准 SQL 行为，PostgreSQL、SQL Server、MySQL 8.0+、Oracle 都支持。
注意：MySQL 5.7 及更早版本对 NULLIF 的 NULL 传播支持不一致，实际执行前建议先测一下 SELECT 10 / NULLIF(0, 0); 是否返回 NULL 而非报错。
怎么写才真正防住除零且不漏数据？
只写 numerator / NULLIF(denominator, 0) 是不够的——它只是把错误变成 NULL，但业务上可能需要默认值、提示或跳过该行。常见组合方式：
- 需要默认值（如 0）：
COALESCE(numerator / NULLIF(denominator, 0), 0) - 需要区分“无意义”和“真实零结果”：
CASE WHEN denominator = 0 THEN 'N/A' ELSE CAST(numerator AS FLOAT) / denominator END（字符串标记比盲目填 0 更安全） - 在聚合中使用（如平均单价）：
AVG(numerator / NULLIF(denominator, 0))—— 此时NULL会被AVG自动忽略，不影响均值计算
NULLIF 和 NULLIF(denominator, 0) 容易踩的坑
别以为写上 NULLIF 就万事大吉。这几个点实际查数据时经常翻车：
-
denominator本身可能是NULL：此时NULLIF(denominator, 0)返回NULL（因为NULL = 0判定为 unknown），再除一次还是NULL。如果业务要求把NULL除数也视作无效，没问题；但如果想把它当成 0 处理，就得先COALESCE(denominator, 0)再套NULLIF。 - 隐式类型转换风险：比如
numerator是整型，denominator是DECIMAL，某些数据库（如 SQL Server）会在除法中做精度截断。建议显式转换：CAST(numerator AS DECIMAL(10,2)) / NULLIF(CAST(denominator AS DECIMAL(10,2)), 0) - WHERE 条件里误用：
WHERE numerator / NULLIF(denominator, 0) > 1会过滤掉所有denominator = 0或NULL的行（因为NULL > 1是 unknown），但如果你本意是“只要分母不为 0 且结果 > 1”，那就对了；如果还想保留分母为 0 的记录做其他处理，就得拆开条件写。
最常被忽略的一点：除零防护不是孤立操作，它必须和上游数据质量、下游消费逻辑对齐。比如报表里显示 NULL，前端没判空就直接 toString()，可能变成 “null” 字符串；又比如导出 Excel 时把 NULL 当空单元格，但业务方以为是漏数。防错代码写得再稳，卡在语义断层里照样出事。
