SQL 谓词下推带来的潜在问题
一、什么是谓词下推？
谓词（Predicate） 在 SQL 中就是你的 WHERE 过滤条件。
谓词下推（Predicate Pushdown） 是数据库的一项核心优化技术，其核心思想是：尽可能提前过滤数据。
数据库优化器通常基于 Cost-Based Optimization 来选择执行计划，而 Predicate Pushdown 就是其中非常常见的一种优化策略。
通俗例子：
你想在果园里找"红色的、甜的"苹果。
普通逻辑：
- 把果园里所有苹果摘下来
- 再挑出红色
- 再判断甜不甜
谓词下推：
- 在树上先判断是不是红色
- 只有红色的才摘下来
这样可以 减少大量不必要的数据处理，因此数据库优化器通常会主动进行这样的优化。
二、为什么会造成报错？
虽然谓词下推能够提升查询性能，但它也可能带来一个问题：
SQL 的执行顺序不一定和书写顺序一致。
很多开发者会直觉认为 WHERE 条件会从左到右执行，但数据库优化器可能会 重新排列或下推条件。
场景设定
假设有一张订单表 orders：
| 字段 | 含义 |
|---|---|
| order_id | 订单ID |
| amount | 商品数量 |
| total_price | 订单总价 |
其中部分历史数据可能存在：
text
amount = 0现在我们想查询：
单价大于 100 的订单
于是写出 SQL：
sql
SELECT *
FROM orders
WHERE amount != 0
AND total_price / amount > 100;很多开发者会认为执行顺序是：
1 先过滤 amount != 0
2 再计算 total_price / amount但数据库优化器可能会生成如下执行计划：
Table Scan
Filter:
amount != 0
total_price / amount > 100也就是说：
两个条件会被同时下推到表扫描阶段执行。
如果数据库在扫描某条数据时：
amount = 0并且先执行：
total_price / amount就可能触发：
Division by zero即使你已经写了：
sql
amount != 0这就是 谓词下推可能带来的隐藏风险。
三、类似风险的常见场景
这种问题通常出现在以下几类计算中：
1 数学运算
例如：
sql
WHERE col2 != 0
AND col1 / col2 > 10如果数据库先执行除法，就可能触发 除零错误。
2 类型转换
例如：
sql
CAST(col AS INT)在某些数据库（如 PostgreSQL）中，如果字段中包含非数字字符串，就可能抛出异常。
3 JSON 解析
例如：
sql
JSON_EXTRACT(profile,'$.age')如果字段不是合法 JSON，也可能导致解析失败。
四、子查询也未必能阻止优化器
很多人会尝试使用子查询来"强制执行顺序"：
sql
SELECT *
FROM (
SELECT * FROM orders WHERE amount != 0
) t
WHERE total_price / amount > 100;看起来像是：
子查询先过滤 amount != 0但数据库优化器仍然可能将条件合并为：
Filter:
amount != 0
total_price / amount > 100这依然属于 谓词下推。
五、解决方案
当 WHERE 条件中存在 可能产生异常的计算 时，需要显式控制计算逻辑。
1 使用 CASE WHEN（推荐）
sql
SELECT *
FROM orders
WHERE
CASE
WHEN amount != 0
THEN total_price / amount
END > 100;这样数据库只有在 amount != 0 时才会执行除法运算，从而避免除零错误。
2 使用 NULLIF
另一种更简洁的写法：
sql
SELECT *
FROM orders
WHERE total_price / NULLIF(amount,0) > 100;NULLIF(amount,0) 会在 amount = 0 时返回 NULL，从而避免除零异常。
六、总结
SQL 优化器的目标是 尽可能高效地执行查询 ，而不是 严格按照 SQL 的书写顺序执行条件。
由于 Predicate Pushdown 的存在：
WHERE条件可能被提前执行- 计算表达式可能在过滤之前发生
- 从而触发异常
因此在编写 SQL 时，如果 WHERE 条件包含以下操作，需要特别注意：
- 数学运算（除法等）
- 类型转换
- JSON 解析
- 字符串解析
一句话总结：
优化器追求的是"快"，而开发者需要保证的是"稳"。