Hibernate Criteria场景下MariaDB查询性能远逊于Oracle的问题排查及优化方案咨询

API 探路者

2026-4-29

问题分析与优化建议

首先，咱们先拆解下核心矛盾：同样的查询逻辑，原生JDBC下Oracle和MariaDB都快，但Hibernate+MariaDB就慢到离谱，且SQL客户端直接执行MariaDB本身也慢。结合你给出的信息，主要原因集中在这几个方面：

一、MariaDB对大量OR条件的优化短板

你生成的SQL是(ID='1') or (ID='2') ... or (ID='10000')，虽然Oracle能把这种超长OR列表高效转化为类似IN的执行计划，但MariaDB默认对这种场景的优化不如Oracle。即使EXPLAIN显示用到了UK_Student索引，实际执行时的扫描、匹配开销还是会比IN子句大很多。

二、字符集排序规则的额外开销

你的MariaDB表用了ucs2_bin排序规则，这种双字节字符集的字符串匹配开销远高于Oracle默认的VARCHAR2（对应utf8/utf8mb4）。尤其是10000次字符串等值匹配，这种差异会被放大。

三、Hibernate与MariaDB驱动的适配问题

虽然你设置了hibernate.jdbc.fetch_size，但MariaDB Connector/J的默认行为可能让这个参数没生效；同时Hibernate对超长SQL的解析、结果集映射逻辑，在MariaDB驱动下的开销也比Oracle大。

具体优化方案

1. 把OR列表改成IN子句（最见效）

别用循环加Disjunction了，直接用Restrictions.in，Hibernate会生成IN ('1','2',...,'10000')的SQL，MariaDB对IN子句的优化远好于大量OR：

Session session = sessionFactory.openSession();
Criteria fetchCriteria = session.createCriteria("Student");
List<String> idList = new ArrayList<>(10000);
for (int i = 1; i <= 10000; i++) {
    idList.add(String.valueOf(i));
}
// 注意：你的代码里用的是"RollNumber"，但生成的SQL是ID字段，这里要和实体类映射一致！
fetchCriteria.add(Restrictions.in("ID", idList));

long start1 = System.currentTimeMillis();
List resultList = fetchCriteria.setFirstResult(0)
                               .setResultTransformer(Criteria.ALIAS_TO_ENTITY_MAP)
                               .list();
long end1 = System.currentTimeMillis();
System.out.println("Time took :"+(end1-start1) +"ms");

2. 强制MariaDB把OR转成IN

如果没法改代码，直接开启MariaDB的优化器开关，让它自动把同字段的多个OR条件转化为IN：

-- 临时生效（重启后失效）
SET GLOBAL optimizer_switch='or_to_in=on';

-- 永久生效，加到my.cnf/my.ini
optimizer_switch = or_to_in=on

3. 调整MariaDB表的字符集排序规则

把ucs2_bin换成utf8mb4_general_ci（或utf8mb4_bin如果需要精确匹配），重建表和索引：

-- 先备份数据，然后修改表
ALTER TABLE student CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
-- 重建索引（可选，确保索引是新字符集）
ALTER TABLE student DROP INDEX UK_student;
ALTER TABLE student ADD UNIQUE KEY UK_student (ID);

4. 优化JDBC驱动参数

在MariaDB的JDBC URL里加上这些参数，提升预处理和结果集传输效率：

jdbc:mariadb://你的地址:端口/库名?useServerPrepStmts=true&cachePrepStmts=true&prepStmtCacheSize=250&prepStmtCacheSqlLimit=20480&useFetchSizeWithLongColumn=true&useBatchMultiSend=true

useServerPrepStmts：启用服务器端预处理，避免每次解析超长SQL
cachePrepStmts：缓存预处理语句
useFetchSizeWithLongColumn：让hibernate.jdbc.fetch_size真正生效，减少网络往返
useBatchMultiSend：优化结果集的批量传输

5. Hibernate层面的小调整

用滚动结果集代替list()，减少内存占用和一次性加载的开销：

ScrollableResults results = fetchCriteria.setFetchSize(100)
                                         .scroll(ScrollMode.FORWARD_ONLY);
List<Map> resultList = new ArrayList<>();
while (results.next()) {
    resultList.add((Map) results.get(0));
}

6. 更新表统计信息

让MariaDB优化器拿到最新的表数据分布，生成更优的执行计划：

ANALYZE TABLE student;

这些方案里，前两个（改IN子句/开启OR转IN）应该能最快看到性能提升，字符集调整则是长期优化的方向。

内容的提问来源于stack exchange，提问作者Developer