根本原因是FetchType.EAGER+多个@OneToMany集合被同时JOIN FETCH时Hibernate无法区分平行关系，导致Oracle 19c执行计划出现CARTESIAN算子和Rows列爆炸，暴露笛卡尔积；验证需查SQL日志与EXPLAIN PLAN，绕过方法包括EntityGraph拆分查询、原生SQL优化或EXISTS替代。
Oracle 19c 下 Hibernate 生成笛卡尔积的典型触发点
根本原因不是 Hibernate 版本或 Oracle 驱动本身，而是 FetchType.EAGER + 多个一对多（@OneToMany）集合被同时 JOIN FETCH 时，Hibernate 无法区分“平行关系”，只能暴力组合。比如一个 Order 同时 JOIN FETCH orderItems 和 orderLogs，而这两张子表都通过 order_id 关联，但彼此无业务关联——Oracle 执行时就会把每条 item 和每条 log 两两配对。
为什么 Oracle 19c 的执行计划里特别容易暴露这个问题
Oracle 19c 的优化器在面对未约束的多表 JOIN 时，更倾向选择 NESTED LOOPS + Cartesian 算子（执行计划中可见 operation = CARTESIAN 或 access by index rowid batched 后紧接全量扫描）。相比 MySQL 的 Using join buffer 提示，Oracle 的 Rows 列爆炸更直观：如果 ORDERS 表只有 100 行，但执行计划里 ORDER_ITEMS 节点显示 Rows = 5000，而 ORDER_LOGS 显示 Rows = 8000，最终结果行数接近 100 × 50 × 80 = 400000，基本坐实笛卡尔积。
如何快速验证是不是 Hibernate 导致的
打开 Hibernate 的 SQL 日志（logging.level.org.hibernate.SQL=DEBUG），找生成的原生 SQL。重点检查：
- 是否含多个
JOIN FETCH指向不同的一对多集合（如JOIN FETCH o.items JOIN FETCH o.logs） - 子查询是否用了
SELECT DISTINCT—— 如果没加，且主实体有多个集合被 fetch，那大概率是它 - 是否在
@Entity类里把两个@OneToMany都设为fetch = FetchType.EAGER，又没做任何聚合控制
用 EXPLAIN PLAN FOR ... 在 Oracle 中跑一遍该 SQL，看 PLAN_TABLE 里有没有 CARTESIAN 或异常高的 CARDINALITY 估算值。
绕过它的实际做法（不改 Hibernate 配置）
不要指望靠 @Fetch(FetchMode.SUBSELECT) 或升级到 Hibernate 6.2+ 就能自动解决——Oracle 19c 对子查询粒度依然敏感。真正有效的路径是主动拆分：
- 用
EntityGraph分两次查：第一次查Order+items，第二次查Order+logs，应用层合并 - 改写成原生 SQL +
@Query，对每个子表先GROUP BY order_id或用ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY id DESC)取最新一条，再LEFT JOIN - 如果只是校验存在性（比如“该订单是否有日志”），直接用
EXISTS子查询替代JOIN FETCH，Hibernate 会生成更干净的WHERE EXISTS (...)
最常被忽略的一点：Oracle 19c 的统计信息若过期，会导致优化器误判 JOIN 顺序，让本可走索引的关联退化为嵌套循环全扫——记得定期 DBMS_STATS.GATHER_TABLE_STATS。
