NULLIF(denominator, 0) 是避免除零错误的最直接方法：分母为0时返回NULL，使整个除法结果为NULL而不报错；参数顺序和括号位置必须正确，否则逻辑失效。
直接用 NULLIF 包住分母，别绕弯
除零报错不是“异常要捕获”，而是“表达式求值前就得把 0 挡掉”。NULLIF(denominator, 0) 是最直的路：它在分母等于 0 时返回 NULL，否则原样返回；而任何数除以 NULL 的结果是 NULL，不报错。
-
NULLIF必须写成NULLIF(denominator, 0)，顺序反了（比如NULLIF(0, denominator)）就完全失效 - 第二个参数必须是字面量
0（整数）或0.0（浮点），不能是列名或表达式，否则语义不对 - 聚合后除法也一样处理：
SUM(revenue) / NULLIF(SUM(cost), 0)，不是NULLIF(SUM(cost), 0)再除——括号位置决定逻辑成败
WHERE 子句里除零会中断整个查询
写 WHERE col_a / col_b > 1 时，只要某行 col_b = 0，整条 SQL 就直接报 division by zero，不是跳过那行，而是查询失败。
- 别指望
AND col_b != 0靠前就能“短路”——SQL 标准不保证执行顺序，有些引擎仍会先算除法 - 安全写法是统一用
WHERE col_a / NULLIF(col_b, 0) > 1，此时col_b = 0行得到NULL > 1→UNKNOWN，自然被WHERE过滤掉 - 如果业务上需要保留分母为 0 的记录（比如视为无穷大），得显式补逻辑：
WHERE col_b = 0 OR col_a / NULLIF(col_b, 0) > 1
想给结果设默认值？COALESCE 或 IFNULL 得包在外层
NULLIF 只负责让除法不崩，返回 NULL；真要替换成 0、1 或其他值，必须再套一层兜底函数。
- 正确：
COALESCE(numerator / NULLIF(denominator, 0), 0)—— 先除，再对结果做兜底 - 错误：
COALESCE(NULLIF(denominator, 0), 0)—— 这是把分母强行变 0 或保留原值，除零风险仍在 - MySQL 用
IFNULL(..., 0)，PostgreSQL/SQL Server 用COALESCE(..., 0)，语义一致 - 注意类型：如果分子是整数、兜底值是小数，某些数据库可能隐式转类型，结果带小数位，业务上是否接受需确认
聚合后除法的两个典型陷阱
COUNT(*) 和 SUM() 本身不会除零，但它们的结果参与除法时，才是雷区。
-
NULLIF(COUNT(*), 0)安全：因为COUNT(*)最小是 0（空组），此时除法无意义，返回NULL合理 -
NULLIF(SUM(cost), 0)要小心：如果数据含正负抵消（如-100 + 100）或全NULL，SUM也可能为 0，这时NULLIF也会生效——但这不是技术问题，是业务逻辑是否允许“净成本为 0”参与计算 - 别用
CASE WHEN SUM(cost) = 0 THEN NULL ELSE numerator / SUM(cost) END：重复计算SUM(cost)两次，窗口函数或大表场景下性能明显下降
NULLIF 参数顺序上。一旦写错，表面不报错，结果却悄悄变成全 NULL 或全默认值，比报错更难排查。 
