SQL Server中除零错误需显式预判而非依赖TRY...CATCH，推荐用CASE WHEN或NULLIF+ISNULL方案：前者灵活可控，后者简洁高效，均能避免报错并返回默认值。
SQL Server 存储过程中除数为零不会自动“异常捕获”，必须显式预判，否则直接报错中断执行（错误号 8134）。
为什么 TRY_CATCH 不能直接解决除数为零
很多人误以为 TRY...CATCH 能兜住除零错误——它确实能捕获，但代价是：语句已中断、事务可能回滚、调用方收到错误信号。这不是“处理”，而是“兜底失败”。真正要的是让计算继续跑下去，不抛错。
关键点：
-
TRY...CATCH适用于不可预知的运行时异常（如对象不存在、权限不足），不是为可控的业务逻辑分支设计的 - 除数是否为零，在执行除法前完全可判断，属于数据逻辑问题，不是系统异常
-
TRY_CAST和除零无关——它只转换数据类型，对INT/0这种运算无效，不会把除零转成NULL
CASE WHEN 是最直观、最可控的预判方式
适合需要差异化处理的场景，比如：除数为 0 时返回 0、NULL、-1 或自定义字符串。
示例（存储过程内片段）：
SELECT
id,
sales,
target,
CASE
WHEN target = 0 THEN 0
ELSE CAST(sales AS DECIMAL(10,2)) / target
END AS achievement_rate
FROM #tmp_data;
注意点：
- 务必先判断
target = 0，再做除法；顺序颠倒就报错 - 如果字段是
INT，建议显式CAST或CONVERT成小数类型，避免整数截断 - 在聚合场景（如
SUM() / COUNT()）中，COUNT()可能为 0，同样要用CASE WHEN COUNT(...) = 0包裹整个表达式
NULLIF + ISNULL/COALESCE 是更简洁的惯用写法
这是 SQL Server 中处理除零的事实标准，语义清晰、性能好、兼容性高。
核心链路：dividend / NULLIF(divisor, 0) → 若 divisor 为 0，则 NULLIF 返回 NULL，整个除法结果为 NULL；再用 ISNULL 或 COALESCE 填充默认值。
示例：
SELECT ISNULL(sales / NULLIF(target, 0), 0) AS achievement_rate FROM #tmp_data;
要点：
-
NULLIF(target, 0)等价于 “如果 target 等于 0，返回 NULL，否则返回 target” -
sales / NULL结果恒为NULL（SQL Server 行为），不会报错 -
ISNULL(..., 0)比COALESCE(..., 0)略快（单参数优化），且类型推导更稳定 - 聚合中照样可用：
ISNULL(SUM(revenue) / NULLIF(COUNT(*), 0), 0)
容易被忽略的边界情况
真实业务里，除数为 0 往往不是孤立数字，而是计算结果或空值传播来的。
常见坑：
-
divisor字段本身是NULL：此时NULLIF(divisor, 0)返回divisor（即NULL），除法仍得NULL——但你可能想区分 “无数据” 和 “分母为 0” - 除数来自子查询或函数（如
ISNULL(GET_TARGET(id), 0)）：确保该表达式不会在除法执行前就因空值或逻辑错误崩掉 - 使用
ARITHABORT OFF或SET ANSI_WARNINGS OFF关闭报错：不推荐。这会让所有算术错误静默失败，掩盖真实问题，且影响执行计划缓存
最稳妥的做法，始终把除数来源显式判断一遍：CASE WHEN ISNULL(target, 0) = 0 THEN ...。
