我一直在阅读一些答案，但我仍然感到困惑。为什么？因为您提到的差异与性能无关。它们与易于使用有关。（Objetc（标准）和 SQL（hql））。但我想知道“标准”是否由于某种原因比 hql 慢。
我在另一个答案中读到了这个
“HQL 和criteriaQuery 在性能方面存在差异，每次使用criteriaQuery 触发查询时，它都会为表名创建一个新别名，该别名不会反映在任何数据库的最后查询缓存中。这会导致编译生成的 SQL 的开销，需要更多时间来执行。”作者：瓦伦·梅塔。
这是非常接近但是！我在另一个网站上阅读（http://gary-rowe.com/agilestack/tag/hibernate/）Hibernate 3.3 及更高版本不再是这种情况（请阅读：9）Hibernate 很慢，因为由Criteria接口不一致）
我已经做了一些测试，试图找出差异，但两者都生成 qry，并且不会更改表的别名。
我很困惑。如果有人知道主要原因，请帮助我们。谢谢
【问题讨论】：
标签： hibernate
总体而言，如果您使用 HQL 或 Criteria 来创建最终 SQL，您将不会看到 Hibernate 的更高版本（3.3 版及更高版本）的性能差异很大。
要对此进行测试，您需要在 HQL 中并使用 Criteria 界面创建一个有代表性的查询。然后记录从逐渐旧版本的 Hibernate 生成的 SQL（可能使用 Maven 以允许快速的版本更改）。您会注意到随着 Hibernate 版本的降低，您会看到最终 SQL 的变化。
在代码中尝试在 HQL 和 Criteria 之间进行优化没有什么意义，因为绝大多数时间浪费在您的应用程序和数据库之间的网络流量上。当然，这假设您有一个格式良好的查询，不需要对一亿行或其他内容进行多次全表扫描。
quoted blog is attempting to debunk myths 所以要小心不要把标题断章取意（强调我的）：
9) "Hibernate 很慢，因为 SQL 由 Criteria 接口生成的是 不一致”
据说 Hibernate 也可以引发性能 如果构造了所有查询，则命中 而是通过 Criteria 接口 的直接在 HQL 中。论据 假设这是因为每次 执行查询生成器代码， 在 DAO 中说，Hibernate 将生成 中表的新别名 询问。在 Oracle 中，这意味着每个 新的基于条件的查询的时间 运行，数据库必须创建一个 QEP—— 查询执行计划——因为它无法 匹配给定的 SQL 任何在其缓存中。创建 QEP 可以 花费 30% 的时间 Oracle 响应一条 SQL 语句， 所以对于第二个和后续 相同的执行（但对于别名 names) SQL 语句，Criteria 有一个 内置开销使其减少 50% 比直接 HQL 慢。
现在情况不再如此 休眠 3.3 及更高版本。 如果是 永远真实是值得怀疑的，因为 Hibernate 团队肯定会致力于 尽可能创建最佳 SQL。 独立测试表明， 相同的查询是由 重复后的条件界面 调用跨越事务是 相当于运行 负载下的应用程序。在每种情况下 查询保持不变并且是 因此能够被 Oracle 缓存。
不过，有一点道理， 因为有必要创建 每次使用 Criteria 查询 接口，而使用命名查询 在 HQL 中定义允许 应用期间的预编译 启动。不过，这需要一些 看法。创建所花费的时间 一个简单的“between”查询，使用 Criteria 接口大约是 在普通 PC 上为 3 毫秒。嵌入 HQL 内应用不好 替代方案，因为它不会导致 一种直观的维护机制 具有不同获取的查询 策略，因此基于标准 方法被认为是更好的 两个。
因此，博客本质上指出，主要区别在于 Criteria 接口可能会引入几毫秒的额外处理开销，这可以通过直接 HQL 方法来避免。 HQL 的查询表达方式也更简洁一些，许多人会觉得很有吸引力。
总之，差别很小，不用担心。
【讨论】：