NULLIF(分母, 0)可避免除零错误，因其在分母为0时返回NULL，使整条除法表达式结果为NULL而非报错；必须置于分母位置，且参数顺序不可颠倒，再配合COALESCE或CASE处理NULL语义。
NULLIF 函数怎么避免除零错误
直接说结论：用 NULLIF(被除数, 0) 把除零变成 NULL，再让整个除法表达式自然返回 NULL 而非报错。这不是绕过问题，而是用 SQL 标准方式把“非法除法”转为“未定义结果”，符合业务中“数据缺失即不参与统计”的常见语义。
为什么不能只写 CASE WHEN divisor = 0 THEN NULL ELSE dividend / divisor END
看起来更直白，但实际有隐患：
- 每次都要重复写
divisor，易出错且难维护 - 在复杂表达式里（比如嵌套子查询或窗口函数中），
CASE会让逻辑膨胀，可读性断崖下降 - 某些数据库（如 PostgreSQL）对
CASE中的除法仍可能做预计算优化，极少数情况下触发除零——而NULLIF是原子函数，语义明确、行为稳定 -
NULLIF(a, b)等价于CASE WHEN a = b THEN NULL ELSE a END，但它是单次求值、无副作用的标准函数
实际写法和典型场景
假设你统计每个用户的订单平均金额，但部分用户总金额为 0（比如只有退款单），此时分母可能为 0：
SELECT user_id, total_amount / NULLIF(order_count, 0) AS avg_order_amount FROM user_stats;
关键点：
-
NULLIF(order_count, 0)在order_count为 0 时返回NULL，否则返回原值 - 任何数除以
NULL结果都是NULL，不会报错，也不会变成无穷大 - 如果分母字段本身可能为
NULL（比如order_count允许空值），NULLIF仍安全：NULLIF(NULL, 0)返回NULL，后续除法继续得NULL - 注意：不要反过来写成
NULLIF(0, order_count)—— 那会把非零值变NULL，逻辑全反了
兼容性和容易踩的坑
所有主流 SQL 引擎都支持 NULLIF（PostgreSQL、MySQL 5.7+、SQL Server、Oracle、SQLite、Trino、DuckDB），但有两个细节常被忽略：
- 参数类型必须严格一致：比如不能写
NULLIF(total_amount, 0)当total_amount是DECIMAL而字面量0被推导为INTEGER—— 某些数据库（如 Presto/Trino）会报类型不匹配。稳妥写法是显式转换：NULLIF(total_amount, CAST(0 AS DECIMAL)) - 它只解决“等于”比较，不处理“接近零”的浮点数。如果分母是
FLOAT类型且可能为极小值（如1e-15），NULLIF不生效，需先用ABS()判断范围，再结合CASE - 别把它当兜底万能药：如果业务上“分母为 0”代表异常状态（比如库存字段为 0 却还在计算周转率），应记录告警或走监控流程，而不是静默转
NULL
真正要小心的，是把 NULLIF 当成“容错开关”后，忘了检查上游数据质量——毕竟 NULL 结果不会报错，但可能掩盖真实的数据采集或清洗漏洞。
