Criteria Api是Hibernate的一个很好的概念。根据我的观点，这些是我们可以区分HQL和Criteria Api的少数点

HQL is to perform both select and non-select operations on the data, but Criteria is only for selecting the data, we cannot perform non-select operations using criteria. HQL is suitable for executing Static Queries, where as Criteria is suitable for executing Dynamic Queries HQL doesn’t support pagination concept, but we can achieve pagination with Criteria. Criteria used to take more time to execute than HQL. With Criteria we are safe with SQL Injection because of its dynamic query generation but in HQL as your queries are either fixed or parametrized, there is no safe from SQL Injection

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

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

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

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

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

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查询现在已被弃用。使用HQL。

We used mainly Criteria in our application in the beginning but after it was replaced with HQL due to the performance issues. Mainly we are using very complex queries with several joins which leads to multiple queries in Criteria but is very optimized in HQL. The case is that we use just several propeties on specific object and not complete objects. With Criteria the problem was also string concatenation. Let say if you need to display name and surname of the user in HQL it is quite easy (name || ' ' || surname) but in Crteria this is not possible. To overcome this we used ResultTransormers, where there were methods where such concatenation was implemented for needed result. Today we mainly use HQL like this:

String hql = "select " +
            "c.uuid as uuid," +
            "c.name as name," +
            "c.objective as objective," +
            "c.startDate as startDate," +
            "c.endDate as endDate," +
            "c.description as description," +
            "s.status as status," +
            "t.type as type " +
            "from " + Campaign.class.getName() + " c " +
            "left join c.type t " +
            "left join c.status s";

Query query =  hibernateTemplate.getSessionFactory().getCurrentSession().getSession(EntityMode.MAP).createQuery(hql);
query.setResultTransformer(Transformers.ALIAS_TO_ENTITY_MAP);
return query.list();

因此，在本例中，返回的记录是所需属性的映射。

当我不知道哪些输入将用于哪些数据时，我通常使用Criteria。就像在一个搜索表单上，用户可以输入1到50个项目中的任何一个，我不知道他们会搜索什么。在检查用户正在搜索的内容时，很容易将更多内容添加到条件中。我认为在这种情况下放置HQL查询会更麻烦一些。当我确切地知道我想要什么时，HQL是很棒的。