使用 NULLIF(SUM(b), 0) 是防止除零错误的最安全做法，它使分母为0时返回NULL，避免报错；需配合乘1.0提升精度，并用COALESCE或CASE做后续展示处理。
直接用 NULLIF 包裹分母是最安全的做法
聚合计算中出现 Msg 8134, Level 16, State 1 或 division by zero 错误，根本原因不是数据脏，而是数据库在执行 SUM(a) / SUM(b) 时遇到 SUM(b) 为 0，数学上无法定义。你不能靠前置 WHERE b != 0 解决——因为聚合后才出分母，WHERE 过滤的是行，不是结果。
正确姿势是把分母替换成 NULLIF(SUM(b), 0)。它会在 SUM(b) 等于 0 时返回 NULL，而任何数除以 NULL 在 SQL 中恒为 NULL，不报错、不中断、语义清晰。
-
NULLIF必须写在分母位置，顺序不能反：✅NULLIF(SUM(b), 0)，❌NULLIF(0, SUM(b)) - 不要在外层套
CASE WHEN SUM(b) = 0 THEN NULL ELSE SUM(a)/SUM(b) END：重复计算SUM，性能差，且聚合函数不能出现在CASE的判断条件里（某些数据库会报错） - 所有主流数据库（PostgreSQL、SQL Server、MySQL 5.7+、SQLite）都支持
NULLIF，行为一致
整数除法导致结果为 0？要主动转浮点
加了 NULLIF 只解决了“不报错”，但若分子分母都是整型，SUM(a) / NULLIF(SUM(b), 0) 仍可能返回截断后的整数。比如 3 / 5 得 0，再 ×100 还是 0，不是 60.0。
必须显式提升精度：
- 写成
SUM(a) * 1.0 / NULLIF(SUM(b), 0)（推荐，兼容性最好） - 或
CAST(SUM(a) AS DECIMAL(10,2)) / NULLIF(SUM(b), 0) - 避免用
AVG()替代：它隐含整除逻辑，且语义不符（客单价不是“每行平均”，而是“总/单数”）
视图或触发器里除零更危险，NULLIF 是前置刚性要求
视图定义是静态的，数据库不会预扫描分母是否全为 0；只要某条结果的分母为 0，整个查询就崩。触发器同理——BEFORE INSERT 里直接写 :new.a / :new.b，一旦 :new.b 是 0，触发器立刻失败，DML 回滚。
这时 NULLIF 不是可选项，是保命线：
- 视图中必须写
num * 1.0 / NULLIF(den, 0)，否则一查就Divide by zero error encountered - 触发器中仍建议先用
NULLIF降低风险，再配合EXCEPTION WHEN ZERO_DIVIDE（Oracle）或TRY...CATCH（SQL Server）兜底设默认值 - 别信“业务上分母不可能为 0”——空时间段、新上线模块、测试数据都可能让
SUM(b)为 0
需要显示 'N/A' 或 0 而不是 NULL？NULLIF 仍是第一道关卡
如果报表要求分母为 0 时显示字符串 'N/A' 或数值 0，不能跳过 NULLIF 直接上 CASE。因为 CASE WHEN SUM(b) = 0 THEN 'N/A' ELSE SUM(a)/SUM(b) END 在 SUM(b) = 0 时仍会先执行除法，报错。
正确链路是：先用 NULLIF 消除硬错，再用 COALESCE 或 CASE 做呈现层转换：
- 显示 0：
COALESCE(SUM(a) * 1.0 / NULLIF(SUM(b), 0), 0) - 显示 'N/A'：
CASE WHEN SUM(b) = 0 THEN 'N/A' ELSE CAST(SUM(a) * 1.0 / NULLIF(SUM(b), 0) AS VARCHAR) END（注意类型转换） -
NULLIF是防御性编程的底层机制，后续处理是业务表达，二者不可互换
真正容易被忽略的点是：NULLIF 只防“值为 0”，不防“值为 NULL”。如果分母字段本身含 NULL，SUM() 已自动忽略它们，所以 NULLIF(SUM(col), 0) 依然安全；但若你在非聚合场景直接用 NULLIF(col, 0)，而 col 是 NULL，它不会转成 NULL——因为 NULL = 0 是 UNKNOWN，NULLIF 直接返回第一个参数（即 NULL），这有时反而符合预期，有时不是。得看上下文。
