NULLIF能拦住除零错误，是因为它在分母等于0时返回NULL，而任何数除以NULL结果为NULL而非报错；必须写成numerator / NULLIF(denominator, 0)，且NULLIF必须直接作用于分母，不可加额外运算或包装。
NULLIF 为什么能拦住除零错误
因为 NULLIF(a, b) 在 a 和 b 相等时返回 NULL，否则返回 a。把它用在除数位置，就能让除数为 0 时变成 NULL，而任何数除以 NULL 的结果也是 NULL（不是报错），SQL 引擎会安静跳过——这是标准 SQL 行为，PostgreSQL、SQL Server、MySQL 8.0+、SQLite 都支持。
怎么写才真正生效：除数必须是 NULLIF 的直接结果
常见错误是套了多余逻辑，比如 100 / (NULLIF(col, 0) + 0) 或 100 / COALESCE(NULLIF(col, 0), 1)，这会让除数变回非 NULL 值，失去保护作用。
- ✅ 正确：除数就是
NULLIF(divisor, 0)，不加任何运算或包装 - ✅ 正确示例：
SELECT amount / NULLIF(quantity, 0) AS unit_price FROM sales; - ❌ 错误示例：
SELECT amount / (NULLIF(quantity, 0) * 1) ...—— 乘 1 不改变值，但让表达式脱离“纯 NULLIF”语义，部分优化器可能绕过空值传播逻辑 - ⚠️ 注意：如果原字段本身可为
NULL，NULLIF(col, 0)仍返回NULL，和除零效果一致，无需额外处理
和 CASE 对比：什么时候不该用 NULLIF
NULLIF 简洁，但只适用于「等于某值就转 NULL」这一种判断。如果你需要更复杂的条件（比如除数 NULL），就得换 CASE。
- 用
NULLIF：仅防 0，接受结果为NULL→val / NULLIF(denom, 0) - 用
CASE：要返回 0 或 -1 或自定义提示 →CASE WHEN denom = 0 THEN 0 ELSE val / denom END - 性能差异极小，但
NULLIF更易读、更难写错；过度嵌套CASE反而增加出错概率
不同数据库的兼容性细节
绝大多数主流系统都支持 NULLIF，但有两点实际中容易卡住：
- MySQL 5.7 及更早版本：支持
NULLIF，但若参与计算的列是DECIMAL类型且精度高，NULLIF(x, 0)可能因隐式类型转换导致结果被截断（不是报错，是数值失真）——建议显式转成统一类型，如NULLIF(CAST(denom AS DECIMAL(10,2)), 0) - SQL Server：如果除数字段是
INT，NULLIF返回仍是INT NULL，整数除法规则照常生效（如5 / 2 = 2），这不是 bug，是类型决定的；需提前转FLOAT或DECIMAL再除 - PostgreSQL：最宽松，
NULLIF类型推导稳定，基本不用额外干预
真正要注意的不是语法对不对，而是除数字段本身的空值、类型、业务含义是否和 NULLIF(x, 0) 的行为完全匹配——比如某个“数量”字段本意是“未填写”才为 NULL，但业务上 0 是合法值，这时用 NULLIF 就刚好；如果 0 是异常录入，那得先清洗数据，而不是靠函数掩盖问题。
