Criteria是一个面向对象的API，而HQL意味着字符串连接。这意味着面向对象的所有好处都适用:

All else being equal, the OO version is somewhat less prone to error. Any old string could get appended into the HQL query, whereas only valid Criteria objects can make it into a Criteria tree. Effectively, the Criteria classes are more constrained. With auto-complete, the OO is more discoverable (and thus easier to use, for me at least). You don't necessarily need to remember which parts of the query go where; the IDE can help you You also don't need to remember the particulars of the syntax (like which symbols go where). All you need to know is how to call methods and create objects.

由于HQL非常像SQL(大多数开发人员已经非常了解SQL)，因此这些“不必记住”参数就没有那么重要了。如果HQL有更大的不同，那么这就更重要了。

对我来说，Criteria是一个很容易理解的动态查询。但我说到目前为止的缺陷是，它加载所有的多-一等关系，因为我们只有三种类型的FetchModes，即选择，代理和默认，在所有这些情况下，它加载多-一(可能是我错了，如果这样帮助我:))

第二个问题与标准是，它加载完整的对象，即，如果我想只是加载一个员工的EmpName，它不会提出这个，而是提出完整的员工对象，我可以从它得到EmpName，因为这真的工作不好的报告。因为HQL只是加载(没有加载关联/关系)你想要的，所以性能会提高很多倍。

Criteria的一个特点是，它将使你免受SQL注入的伤害，因为它的动态查询生成，而在HQL中，ur的查询要么是固定的，要么是参数化的，因此在SQL注入中不安全。

同样，如果你在你的aspx.cs文件中编写HQL，那么你与你的DAL紧密耦合。

总的来说，我的结论是，有些地方你不能没有HQL，比如报告，所以使用它们，否则Criteria更容易管理。

条件是指定利用第二级查询缓存中的特殊优化的自然键查找的唯一方法。HQL没有任何方法来指定必要的提示。

你可以在这里找到更多信息:

http://tech.puredanger.com/2009/07/10/hibernate-query-cache/

还有另一种方法。我最终创建了一个基于hibernate原始语法的HQL解析器，这样它就可以首先解析HQL，然后动态地注入动态参数或自动为HQL查询添加一些通用过滤器。效果很好!

另一点是，我认为Criteria更适合在它的基础上构建，而不是在最终代码中直接使用。

它更适合使用它来构建库，而不是使用jpql或hql。

例如，我使用Criteria API构建了spring-data-jpa-mongodb-expressions(与spring数据QBE的方式相同)。

我认为spring数据查询代使用jpaql而不是标准，我不明白为什么。

这里的大多数答案都是误导性的，并提到标准查询比HQL慢，但事实并非如此。

如果你深入研究并执行一些测试，你会发现标准查询比常规HQL执行得更好。

同样，通过Criteria Query，你可以得到HQL所没有的面向对象的控制。

更多信息请阅读这里的答案。