直接写 SELECT a/b 会报错，因为除零错误发生在表达式求值阶段，而 WHERE 无法过滤聚合后为0的分母；必须用 NULLIF(b, 0) 在分母上提前转为 NULL，确保除法安全。
为什么直接写 SELECT a/b 会报错？
当 b 列存在 0 或 NULL 值时，多数数据库（如 PostgreSQL、SQL Server）会在执行阶段抛出除零错误，比如 division by zero。MySQL 默认容忍该操作并返回 NULL，但这是非标准行为且受 sql_mode 控制——不能依赖。关键在于：**错误发生在表达式求值阶段，而这个阶段无法用 WHERE 提前过滤掉分母为零的行，因为 WHERE 是在 FROM 之后执行的。**
用 FROM 子查询预处理分母，把风险前置
核心思路是：把原始表包装进一个子查询，在子查询里先计算并修正分母，确保它永远不会是 0；外层再安全地做除法。这不是绕开问题，而是把校验逻辑放到执行链更早的位置。
常见做法包括：
- 用
CASE WHEN b = 0 THEN NULL ELSE b END替换原分母列 - 用
NULLIF(b, 0)（PostgreSQL/SQL Server/MySQL 5.7+ 支持），它等价于上一条但更简洁 - 若业务允许兜底值（如用
1代替0），可用COALESCE(NULLIF(b, 0), 1)
示例（PostgreSQL）：
SELECT a / b_safe AS result FROM ( SELECT a, NULLIF(b, 0) AS b_safe FROM numbers ) AS safe_data;
FROM 子查询 vs CASE 在 SELECT 中的区别
看起来都能避免除零，但执行时机和语义不同：
-
CASE WHEN b = 0 THEN NULL ELSE a/b END：仍会尝试计算a/b，某些数据库（如 SQL Server）仍可能触发除零异常，取决于优化器是否下推判断 -
FROM子查询中先替换分母：确保b_safe永远不是0，后续除法表达式天然安全，无歧义 - 性能上差异通常可忽略，但子查询方式逻辑更清晰、行为更确定
注意 MySQL 的陷阱：默认不报错 ≠ 安全
MySQL 在宽松模式下对 1/0 返回 NULL，但这容易掩盖真实数据问题。一旦切换到严格模式（STRICT_TRANS_TABLES），同样报错。所以不能靠“我本地没报错”来验证逻辑正确性。
真正可靠的写法仍是统一用 FROM 子查询 + NULLIF，或显式 CASE 处理分母，且必须在所有目标数据库上验证行为一致。
复杂点往往不在语法，而在你没意识到：除零检查必须发生在除法运算之前，而 SQL 执行顺序决定了只有 FROM 阶段能稳稳卡住这个时机。
