对于动态条件查询，我们可以根据我们的输入构造查询..在Hql查询是静态查询的情况下，一旦我们构造，我们就不能改变查询的结构。

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

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

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

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

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

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

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

HQL和criteriaQuery在性能上是有区别的，每次你使用criteriaQuery发起查询时，它会为表名创建一个新的别名，这个别名不会反映在任何DB的最后一个查询缓存中。这会导致编译生成的SQL的开销，需要更多的时间来执行。

关于抓取策略[http://www.hibernate.org/315.html]

Criteria respects the laziness settings in your mappings and guarantees that what you want loaded is loaded. This means one Criteria query might result in several SQL immediate SELECT statements to fetch the subgraph with all non-lazy mapped associations and collections. If you want to change the "how" and even the "what", use setFetchMode() to enable or disable outer join fetching for a particular collection or association. Criteria queries also completely respect the fetching strategy (join vs select vs subselect). HQL respects the laziness settings in your mappings and guarantees that what you want loaded is loaded. This means one HQL query might result in several SQL immediate SELECT statements to fetch the subgraph with all non-lazy mapped associations and collections. If you want to change the "how" and even the "what", use LEFT JOIN FETCH to enable outer-join fetching for a particular collection or nullable many-to-one or one-to-one association, or JOIN FETCH to enable inner join fetching for a non-nullable many-to-one or one-to-one association. HQL queries do not respect any fetch="join" defined in the mapping document.

对我来说，Criteria最大的优势是示例API，在这里你可以传递一个对象，hibernate将基于这些对象属性构建一个查询。

除此之外，标准API也有它的怪癖(我相信hibernate团队正在重做API)，比如:

a criteria.createAlias("obj")强制使用内部连接而不是可能的外部连接 您不能两次创建相同的别名 有些SQL子句没有简单的对应条件(比如子选择) 等。

当我想要类似于sql的查询时，我倾向于使用HQL(从用户中删除status='blocked')，当我不想使用字符串追加时，我倾向于使用标准。

HQL的另一个优点是您可以预先定义所有的查询，甚至可以将它们外部化到一个文件中。

HQL可能会导致SQL注入等安全问题。