一个程序上线三周后客服开始零星反馈某个查询页面“偶尔查不出数据”。应用日志没有异常，慢查询列表里找不到它。把 SQL 拷到客户端里手工执行，结果完全正常。

这类问题通常要查很久，因为它不符合大多数人对故障的想象。其实，它不报错，不告警，监控面板一片正常，只是在某些时刻安静地返回零行。等到定位出来往往已经过去几天中间产生的错误数据还要对了花时间对账。

生产环境里真正昂贵的 SQL 问题，很少是语法错误。语法错误在开发阶段就被拦下了。怎么说呢，剩下能活到生产的，都是那些“能跑”的写法。

一、一条依赖执行顺序的 SQL

先看一个具体的例子。业务上需要先设置一个上下文变量，再用这个变量参与过滤。有人把两件事写进了同一条语句：

SELECT * FROM my_table
WHERE id1 = pkg_abc.get_id -- 取值
AND pkg_abc.set_id =;按理说，-- 赋值并返回

写法的意图很清楚。靠 WHERE 子句中条件的书写顺序来控制两个函数的执行先后。阶段测过能出数据，测试环境测过也能出数据；老实说，上线以后一开始好时坏。

在 Oracle 上，两个对等的等式比较通常按从左到右求值。左边的 id1 = get_id 先执行。此时 set_id 还没有运行，包变量为空，比较结果为假。基于短路求值，右边的 set_id 可能根本不会被触发。整条语句返回零行，更麻烦的是等式与不等式混合出现，调整器有可能重新调度条件的求值次序。执行顺序并不严格锁定在代码的书写位置上。

KES 在兼容性设计上对这一点做了明确约定：WHERE 子句中的函数条件。无论等式还是不等式，都默认按条件出现的先后顺序从左到右依次求值。规则是确定的，也是可查的。

这里需要说清楚一件事：内核给出了确定行为，不等于这条 SQL 就是安全的。确定的是求值顺序，不确定的是这条语句所依赖那个变量在执行前处于什么状态——而后者才是它时好时坏真正原因。

二、真正的隐患在会话，不在语法

包级别全局变量生命周期是整个会话。怎么说呢，

在客户端工具里调试时人们习惯先跑一遍正确写法。让变量被赋上了值，会话一直保持着。接下来再执行那条顺序写反的 SQL，因为会话里残留着上一次的值。它照样能返回结果，于是得出这条 SQL 没问题。

这个结论在那个客户端窗口里成立，但换到生产就不成立。不过，

应用通过连接池访问数据库。每次请求拿到的是哪条物理连接，上一个使用者在这条连接上留下了什么状态？应用层完全不知道，连接被回收、重建、扩容都会重置这些残留值。至于行为变成，有残留值时正常，无残留值时返回空集；连接池在业务高峰扩出几条新连接，新连接上的请求就集体查不到数据；应用重启一次现象又变了，

• 排查经验：
• ① 用 explain analyze 看实际执行中 Filter 条件排列和各条件实际调用次数；不要凭书写顺序推测——计划里写着才是真的发生过。
• ② 一旦发现同一条 SQL 的行为与会话相关——重启应用即可解决、换连线又不行、同一会话连着执行两次结果不同——第一顺位怀疑对象就是包变量、会话级临时表和会话级参数，而不是数据本身；按会话去查通常比逐行核对数据快得多。

三、这类风险的共同特征

This case abstracted shows that many production incidents belong to same category.

• 静默性：No error or alert—just incorrect results or performance degradation that bypasses most monitoring.

• 环境相关性：The bug does not reproduce in test because data volume。concurrency,connection‑pool behavior and statistics differ.

• 迁移放大效应：A piece of code that “always worked” in its original environment may fail once moved because implementation details change.

*判断标准*

"这个行为，是标准和文档承诺的吗？还是当前实现恰好如此，"

• 工程态度：If it follows documented semantics.

• 娱乐态度：If it relies on undocumented implementation quirks—risking failure at next minor version upgrade or when optimizer changes plans.

*四、通用编码规范*

• . 不要在 WHERE/ON/HING 中调用带副作用函数: 修改数据/会话状态/日志/外部接口都算副作用。这些函数进入过滤条件后其执行次数和是否短路完全由调整器决定，没有任何书面承诺。- 推荐做法：把状态设置彻底移出查询。在应用层或存储过程中先调用set_id,再发起干净 SELECT；更好的办法是直接将该参数绑定进查询。- 成本主要来自确认该参数来源，而非技术实现本身。
• . 如实声明函数易变性: 使用者自定义函数默认 VOLATILE。说起来，- IMMUTABLE 等价于“相同输入永远得到相同输出”。允许缓存和索引调整，但若读取表就可能导致计划变化导致问题突然出现。 - STABLE 标记用于“只读表且单语句内保持一致”，VOLATILE 用于“每次调用可能不同”。- 在迁移项目中，可先全部设为 VOLATILE 保底。再针对热点 SQL 的关键函数逐个校正。
• . 不要用会话级状态跨语句传递数据: 包变量、临时表和参数均属于会话生命周期，在连接池模型下复用资源容易产生残留状态。按理说，- 推荐做法：跨语句传递状态放至应用层。仅使用参数传递给 SQL；如必须使用，需要显式初始化与清理，并评估额外开销。
• . 没有 ORDER BY 就没有顺序: “按主键自然排序”只是当前计划副作用。当索引扫描或并行化改动后返回顺序可随之改变。- 分页必须包含唯一列作为 ORDER BY 键，并采用键值分页避免 OFFSET 导致重复或丢失记录。
• . 保证比较两端的数据类型一致: 隐式转换导致索引失效。只能退化为全表扫描，从小表无感，到大表慢查询暴露。- 对齐常量类型，在驱动层绑定正确类型，并是否出现 Seq Scan。不过，
• <强>. 按三值逻辑处理 NULL : NOT IN 与子查询含 NULL 会返回空集。要改为 NOT EXISTS 或显式 IS NULL 判断。- 注意 COUNT 与 COUNT 区别，在核对数据时差异可能导致部门误解。不过，
• <强>. 一律使用绑定变量 : 拼接字符串导致每条生成新计划。占用缓存并增加解析负担，- 推荐预编译 + 参数绑定，包括 IN 列表可使用数组参数配合 = ANY;提高计划复用率，
• <强>. 把事务边界压到最小 : 长时间未提交事务阻止 MVCC 清理旧版本，引起膨胀与性能下降。- 在事务中避免人机交互与外部调用；单语句完成即提交，数据库侧设置空闲事务超时作为保险。
• <强>. DDL 与批量 DML 要考虑锁影响 : 大型结构变更或批量更新可能持锁长时间，引发整个应用不可用。- 建索引使用并发方式，设置锁等待超时且支持失败重试；话说回来，分批提交并控制单批规模。* 明确列出需要列，不要 SELECT *** : 多余 I/O 与网络传输之外还存在因列顺序耦合导致字段错位的问题。在视图中尤其危险，以基表结构变化为触发点产生意料之外的数据错乱。

  *五、规范落地靠工具。不靠人眼*

  • 评审现场难以拦截这些看似“正常”的代码，因为它们未报错且测试通过却隐藏真实风险。
  • 自动化检查覆盖范围应包括： * 函数调用位置与副作用检测；* 参数类型匹配检查，* NULL 三元逻辑验证；* ORDER BY 唯一性检查；* 参数绑定完整性验证，* DDL 与批量 DML 锁冲突预判；按理说，* 长事务检测与超时配置校验；* 对 SELECT *** 的警告及建议改为显式列列表；* 实际运行中持续观察 EXPLAIN PLAN 和资源指标变化，以捕捉调整器切换带来的性能波动和潜在错误产生点。

    *金仓智能运维工具大赛*

    电科金仓正在举办金仓数据库智能运维工具开发大赛。与 ITPUB、佰晟智算及海光信息联合，为 DBA、开发者及数据库使用者提供参赛教程，包括 BIC‑QA 数据库诊断工具开发指导。本次比赛旨在逼迫参赛者将经验转化为可复现规则，从而降低团队踩坑概率。并将检查项纳入自动化流程，实现“第二个人不会再踩同一个坑”。参与价值不仅仅体现在排名，更体现在长期维护成本的大幅下降上。怎么说呢，

    *六、迁移搬的是语法。留下的是隐含约定*

    这几年众多团队把长期运行程序从原有数据库迁移至国产数据库。在评估阶段，大多数——即那些未落纸面却被团队内部视作“默认”且长期稳定运行所隐藏的问题。当维护人员轮换或程序升级至新内核，这些隐含约定往往成为致命缺口。使得原本无异常的小细节突然爆炸成灾难性错误。

    • 如果你正准备迁移。请务必先梳理所有曾经“一直这么写，一直没事”的地方，对其实现细节进行追问。如果能够解释清楚，则可以纳入规范；如果无法回答，则很可能成为迁移后的首要故障源头。需要提前准备回退方案或设计修复方法。主要就一句话这方面，数据库只负责回答“一段 SQL 能否成功执行”。但决定是否这样编写则只能由编程团队自己承担责任，将潜在风险转化为可检验规则，以防止未来不可预知的问题 发生。