在 WHERE 子句里放一个有副作用的函数就像在高速公路上放了一个随机变道的司机——也许今天没事但迟早会出事故。引言一段看起来理所当然的代码在一次代码评审中我看到了这样一条 SQLSELECT * FROM employees WHERE get_department_id() set_department_id(IT) 0;编写者的意图很明确先调用set_department_id(IT)设置一个全局变量然后调用get_department_id()读取它用这个值去过滤employees表。他的理由是在 KES 里WHERE 子句是从左到右执行的所以set一定先于get执行没问题。听起来有道理。但作为经历过线上事故的 DBA我背后的冷汗瞬间就下来了。这段代码有三个致命问题它依赖于函数的执行顺序它依赖于函数的副作用修改全局状态它假设了数据库版本的行为一致性本文将深入解析为什么在WHERE子句中依赖函数执行顺序是不安全的以及 KES 和 Oracle 在这个问题上的不同处理方式。一、核心问题WHERE 中的函数执行顺序到底确不确定1.1 Oracle 的不确定性在 Oracle 中WHERE子句中多个函数的执行顺序没有保证。虽然通常从左到右执行但 Oracle 优化器可能基于以下原因调整执行顺序谓词重排Predicate Reordering优化器根据过滤率和代价重新排列WHERE条件中各表达式的求值顺序以尽早过滤掉不满足条件的行短路优化如果一个条件已经能确定整个WHERE表达式的真假优化器可能跳过其他条件并行执行在并行查询中不同片段可能在不同线程上以不同顺序执行这意味着今天从左到右执行的代码明天换个执行计划可能就从右到左了。1.2 KES 的确定性路径金仓数据库 KES 在这个问题上采取了更为确定的策略KES 严格按 WHERE 子句中表达式的书写顺序从左到右依次执行无论等式还是不等式。这一设计降低了开发者的认知负担——你写的顺序就是执行顺序。但请注意确定性不等于安全性。为什么因为KES 未来版本可能引入谓词重排优化其他主流数据库都有这个特性即使当前版本确定依赖执行顺序的代码也缺乏可移植性1.3 对比总结维度OracleKES当前版本执行顺序保证不保证优化器可能重排保证严格从左到右谓词重排支持当前不支持未来变更风险高行为已不确定中未来可能引入重排跨版本可移植性差差不建议依赖此行为结论无论在哪种数据库中依赖WHERE子句中的函数执行顺序都是不安全的做法。二、为什么这种做法如此危险2.1 会话污染全局变量的定时炸弹让我们回到文章开头的例子SELECT * FROM employees WHERE get_department_id() set_department_id(IT) 0;假设这段代码在开发环境中正常工作了。问题出在生产环境场景 1连接池复用生产环境使用连接池。连接被归还给连接池后set_department_id设置的会话级变量不会被清除。下一个复用该连接的查询可能读到的是上一个查询残留的值。连接 1: set_department_id(IT) → 查询 → 归还连接池 会话变量仍为 IT 连接 2: 复用连接 1 → get_department_id() → 读到 IT 但连接 2 的本意是查 HR结果查询返回了错误的数据且没有任何报错。这种静默错误是最难排查的。场景 2并发查询多个并发会话同时调用set_department_id全局变量被互相覆盖。在高并发场景下查询结果变得不可预测。2.2 优化器重写的潜在风险即使 KES 当前版本保证从左到右执行但这不意味着未来不会改变。数据库优化器的发展方向是越来越智能——谓词重排是提升查询性能的标准技术之一。如果未来 KES 版本引入了谓词重排优化这段代码的执行顺序可能突然改变导致get在set之前执行 → 读到旧值 → 查询结果错误没有任何版本升级警告或错误提示这种静默行为变更是生产环境中最危险的问题类型。2.3 函数挥发度Volatility的影响数据库中的函数通常有一个挥发度标记Volatility用于告知优化器函数的行为特征挥发度含义优化器行为IMMUTABLE相同输入永远返回相同输出无副作用可以缓存结果、提前求值STABLE同一事务内相同输入返回相同输出可在事务内缓存VOLATILE每次调用可能返回不同结果或有副作用必须每次求值不可优化如果函数没有正确声明挥发度默认通常是VOLATILE优化器可能做出错误的优化决策。反之如果将有副作用的函数错误声明为STABLE或IMMUTABLE优化器可能缓存结果或跳过调用导致副作用不被执行。三、解决方案如何安全地处理先 Set 后 Get的需求3.1 方案一通过存储过程显式完成 Set 操作推荐将有副作用的操作从 SQL 表达式中剥离在存储过程或匿名块中显式执行-- KES PL/SQL 匿名块 BEGIN set_department_id(IT); -- 设置完成后再执行查询 FOR rec IN (SELECT * FROM employees WHERE dept_id get_department_id()) LOOP -- 处理结果 END LOOP; END; /这种方式的优势执行顺序显式可控——BEGIN到END之间的语句严格按书写顺序执行副作用与查询分离——避免了在表达式中嵌入有副作用的调用可读性更好——代码意图一目了然3.2 方案二通过参数传递避免全局状态如果你只是想传递一个过滤值给查询最直接的方式是用参数-- 在应用层设置参数 PREPARE stmt AS SELECT * FROM employees WHERE dept_id $1; EXECUTE stmt(IT);或者在存储过程中CREATE OR REPLACE PROCEDURE query_by_dept(p_dept_id VARCHAR) AS BEGIN FOR rec IN (SELECT * FROM employees WHERE dept_id p_dept_id) LOOP -- 处理结果 END LOOP; END; /用参数替代全局变量从根本上消除了会话污染的风险。3.3 方案三正确声明函数挥发度对于纯读取、无副作用的函数务必声明正确的挥发度-- 纯读取函数声明为 STABLE CREATE OR REPLACE FUNCTION get_department_name(dept_id INTEGER) RETURNS VARCHAR STABLE -- 告知优化器同一事务内相同输入返回相同输出 AS $$ SELECT dept_name FROM departments WHERE id $1; $$ LANGUAGE SQL; -- 计算函数声明为 IMMUTABLE CREATE OR REPLACE FUNCTION calculate_bonus(salary NUMERIC) RETURNS NUMERIC IMMUTABLE -- 告知优化器相同输入永远返回相同输出 AS $$ SELECT salary * 0.1; $$ LANGUAGE SQL;正确的挥发度声明能帮助优化器做出更好的决策同时避免对有副作用的函数进行不当优化。3.4 方案四使用 WITH 子句确保执行顺序在 KES 中WITH子句CTE可以保证内部语句的执行顺序。虽然这不是标准 SQL 的语义保证但 KES 当前版本中 CTE 不会被内联优化WITH setup AS ( SELECT set_department_id(IT) AS result ) SELECT * FROM employees, setup WHERE dept_id get_department_id();注意这种方式依赖于 KES 的 CTE 实现细节未来版本如果引入 CTE 内联优化行为可能改变。因此仅作为临时方案不作为长期推荐。四、铁律总结以下是你在数据库开发中应该牢记的几条铁律严禁在 WHERE 中放置有副作用的函数——包括但不限于修改全局变量、写日志、发送消息、修改表数据等。通过存储过程或匿名块显式完成 Set 操作——将副作用操作与查询分离确保执行顺序可控。纯读取函数声明为 STABLE 或 IMMUTABLE——帮助优化器正确决策避免不必要的重复调用。永远不要假设 WHERE 子句的执行顺序——即使在当前版本中是确定的也不代表未来版本或其他数据库中保持一致。用参数替代全局变量——在连接池环境下全局变量是定时炸弹。总结在WHERE子句中依赖函数执行顺序是一种看似工作、迟早爆炸的反模式。KES 当前版本虽然保证了从左到右的执行顺序但这不应成为你编写依赖此行为代码的理由。原因有三会话污染连接池环境下的全局变量残留会导致静默数据错误未来风险优化器升级可能引入谓词重排改变执行顺序可移植性依赖特定数据库实现细节的代码无法跨库迁移正确的做法是将有副作用的操作从 SQL 表达式中剥离通过存储过程、参数传递或正确的函数挥发度声明来替代。简洁、显式、可预测——这是所有优秀数据库代码的共同特征。本文基于金仓数据库 KingbaseES V9 / Oracle 19c 编写。函数挥发度说明参考 PostgreSQL / KES 函数定义规范。