本文揭示了一个隐蔽但关键的兼容性问题：相同 JPA Query 在 Oracle 21c 与 Oracle 18 上执行结果不同，根源在于 Oracle 21c 对 SQL 布尔表达式求值顺序的优化变更，影响了 QueryDSL 生成的 OR + AND 混合条件的实际语义。
本文揭示了一个隐蔽但关键的兼容性问题：相同 jpa query 在 oracle 21c 与 oracle 18 上执行结果不同，根源在于 oracle 21c 对 sql 布尔表达式求值顺序的优化变更，影响了 querydsl 生成的 `or` + `and` 混合条件的实际语义。
在使用 Spring Data JPA 与 QueryDSL（v3.7.4）构建业务逻辑时，开发者常依赖 BooleanBuilder 组合动态查询条件。然而，当底层数据库升级至 Oracle Database 21c Express Edition（21.0.0.0.0）后，部分原本稳定的查询意外失效——同一段代码、同一 commit、同一数据集，在 Oracle 18 环境下返回预期空结果，而在 Oracle 21c 下却错误地匹配到自身实体。
问题核心出现在如下典型去重校验逻辑中：
BooleanBuilder condition = new BooleanBuilder(); condition.or(QCustomer.customer.registerNr.eq(inputCustomer.getRegisterNr())); condition.or(QCustomer.customer.email.eq(inputCustomer.getEmail())); // 实际应为不同字段 JPAQuery query = new JPAQuery().from(QCustomer.customer).where(condition); query.where(QCustomer.customer.id.ne(inputCustomer.getId())); // 排除自身 Customer existing = customerDAO.findOne(query); // ❌ Oracle 21c 中此行可能返回 inputCustomer 自身！
生成的 SQL 形如：
SELECT * FROM customer WHERE (register_nr = ? OR email = ?) AND id <> ?
该 SQL 在标准 SQL 语义下完全正确，且在 Oracle 18、PostgreSQL、H2 等环境中均表现一致。但 Oracle 21c 引入了更激进的谓词重写（Predicate Pushdown）与短路求值优化策略。在特定条件下（尤其是重复或冗余 OR 子句、绑定变量类型推导差异），其查询优化器可能将 AND id ? 仅应用于部分 OR 分支，等效于：
WHERE register_nr = ? OR (email = ? AND id <> ?) -- ❌ 非预期语义
这直接导致 id ? 过滤失效，使当前待校验实体被错误包含在结果集中。
✅ 验证方法：
将生成的 SQL 直接在 Oracle 21c SQL*Plus 或 SQL Developer 中执行，确认结果是否异常；再对比 Oracle 18 的执行结果。若仅数据库版本差异导致行为变化，则可锁定为 Oracle 兼容性问题。
⚠️ 关键注意事项：
- 此问题非 JPA/Hibernate Bug，也非 QueryDSL 逻辑错误，而是 Oracle 21c 优化器行为变更引发的语义漂移；
- 升级驱动（如 ojdbc8 → ojdbc11）无法解决，因问题位于数据库服务端执行计划层面；
- 修改 Java 代码（如拆分查询、改用 @Query 原生 SQL）虽可行，但违背“最小改动”原则，且掩盖了根本环境风险。
根本解决方案是统一开发环境数据库版本。团队已验证：将本地 Oracle 21c 降级至 Oracle 18c（18.4.0.0.0 或更高 18.x 补丁集）后，问题立即消失，所有查询回归预期行为。这不仅是临时规避，更是保障 CI/CD 流水线、本地调试与生产环境行为一致性的必要实践。
? 建议行动项：
- 在项目根目录添加 docker-compose.yml，声明标准化 Oracle 18 镜像（如 gvenzl/oracle-xe:18-slim）供所有开发者复用；
- 在 README.md 中明确标注“开发数据库要求：Oracle 18c+”，并提供一键启动脚本；
- 对关键业务查询（尤其含 OR + 排除条件组合）补充集成测试，覆盖多数据库版本断言。
版本一致性不是运维负担，而是质量防线的第一道闸门。
