MySQL中用NULLIF(divisor, 0)可避免除零错误，使除数为0时返回NULL，从而整个表达式静默返回NULL而非报错；再套IFNULL可设默认值，该写法在PostgreSQL和SQL Server中同样适用。
MySQL 中用 NULLIF 避免除零错误
MySQL 直接执行 SELECT 10 / 0 会报错 Division by zero，不能靠 IFNULL 或 COALESCE 预先捕获——因为除法运算本身在参数求值后才执行，而除零是运行时错误。正确做法是让除数在为零时变成 NULL，触发 SQL 标准中“任何数除以 NULL 返回 NULL”的行为。
核心技巧是用 NULLIF(divisor, 0)：它在除数等于 0 时返回 NULL，否则返回原值。这样整个表达式不会报错，而是静默返回 NULL。
-
SELECT 10 / NULLIF(0, 0);→ 返回NULL（不报错） -
SELECT 10 / NULLIF(5, 0);→ 返回2.0000 - 若想把结果中的
NULL替换为默认值（如 0），再套一层IFNULL(..., 0)：SELECT IFNULL(10 / NULLIF(col_b, 0), 0)
PostgreSQL 和 SQL Server 的等效写法
PostgreSQL 完全支持 NULLIF，用法和 MySQL 一致；SQL Server 同样支持，且兼容性好（2005+ 版本均可）。但注意：SQL Server 默认开启 ARITHABORT OFF 时，某些除零场景可能返回 NULL 而非报错，但这属于会话级隐式行为，不可靠——仍应显式使用 NULLIF 统一处理逻辑。
- 三者通用安全写法：
numerator / NULLIF(denominator, 0) - PostgreSQL 还可配合
NULLIF+COALESCE：COALESCE(numerator / NULLIF(denominator, 0), 0) - 避免用
CASE WHEN denominator = 0 THEN NULL ELSE numerator / denominator END——逻辑等价但多写、易漏括号，且部分旧版 PostgreSQL 对ELSE分支的除法仍可能提前校验
WHERE 条件中除零导致过滤失效的问题
当在 WHERE 子句里写类似 WHERE col_a / col_b > 1，如果 col_b 有 0 值，整行会因报错而中断查询，不是跳过该行。这不是数据过滤问题，是语句执行失败。
- 必须改写为：
WHERE col_b != 0 AND col_a / col_b > 1，但注意：SQL 标准不保证短路求值，AND左右顺序不一定生效 - 更可靠的是：
WHERE col_a / NULLIF(col_b, 0) > 1，此时除零转为NULL，而NULL > 1结果为UNKNOWN，该行自然被WHERE排除 - 若业务上允许分母为 0 的记录参与比较（比如视为无穷大），那就需要额外
OR col_b = 0显式覆盖逻辑
除零之外的浮点边界情况也要留意
NULLIF(x, 0) 只防整数 0 和精确浮点 0.0，但对极小浮点数（如 1e-308）不做处理——它们不会报错，但可能导致结果溢出或精度丢失。如果业务敏感，需结合 ABS(denominator) > 1e-10 做兜底判断。
- 例如：
numerator / NULLIF(CASE WHEN ABS(denominator) - 不要依赖
TRY_CAST或存储过程异常捕获来处理除零——开销大、不可移植，且掩盖了本该由数据逻辑预防的问题 - 真正健壮的做法，是在 ETL 或应用层确保分母字段有约束（如
CHECK (col_b != 0)），数据库层的NULLIF是最后一道防线，不是替代方案
