java - Hibernate session.createCriteria 与 session.get 性能对比

Question

我们的开发团队最近开始担心标准和 HQL 太慢。我运行了一些基准测试来了解缓慢的原因。

我每个运行以下查询 1001 次。我第一次运行查询时， session 不会缓存实体，但此后每次都会缓存实体。

Entity e = (Entity) session.get(Entity.class, new EntityID("Composite key value 1", "Composite key value 2"));

First call: 
    80.505875
Average of next 1000 calls:
    0.045958 ms

Entity e = (Entity) session.createCriteria(Entity.class)
        .add(Restrictions.eq("id", new EntityID("Composite key value 1", "Composite key value 2")))
        .uniqueResult();

First call: 
    91.489098 ms
Average of next 1000 calls:
    0.847434 ms

顺便说一句，HQL 中的相同查询第一次花费的时间更长，但在所有后续调用中统计上是等效的。

我了解到，与数据库查询相比，HQL 的标准以及 HQL 到 SQL 的转换所花费的时间微不足道。根据我的测试，这些翻译的时间似乎是 session 时间的 18.4 倍。

0.847434 / 0.045958 = 18.439314

假设一些实现细节，我预计查询的转换需要 0.801476 毫秒。这意味着转换步骤需要 session 时间的 17.4 倍时间。使用 JDBC，我们可以在 0.025368 毫秒内运行这些查询。这是一个以前使用 ODBC 的转换项目，因此我们正在寻找与之前的速度相当的速度。然而，即使使用缓存，我们似乎也无法达到可比的速度。

(0.847434 - 0.045958) / 0.045958 = 17.439314

我预计，通过使用缓存来避免与数据库通信，我们在后续调用中将达到与 JDBC 相当的速度。标准翻译需要一毫秒的时间来运行是否正常？人们如何通过使用标准的缓存来达到与 JDBC 相当的速度？

编辑:我的帖子包含一个重大错误，似乎相同的代码产生了两个不同的统计数据。此问题现已修复。

Answer 1

I ran the following queries 1001 times each. The first time I run the query the entity is not cached by the session, but every time after that the session is cached.

你的假设是错误的。使用 Criteria API 时，条件查询不会缓存在持久性上下文中。即使您使用 id 属性，也会执行 SQL 查询。而使用 get 方法时，对象确实维护在一级缓存(持久化上下文)中。

您可以通过启用 show_sql=true 来验证它。对于第一个用例，您将看到单个查询打印输出。对于条件，您将看到 1000 个查询。

第一次预热调用速度明显变慢的原因是必须从池中获取/创建连接，可能缓存一条语句等。

也就是说，将 setCacheable(true) 添加到条件中，您将看到平均时间下降到接近调用 get 的水平。