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有更大的不同，那么这就更重要了。

HQL更容易阅读，更容易使用Eclipse Hibernate插件等工具进行调试，也更容易记录日志。条件查询更适合构建动态查询，其中许多行为都是在运行时确定的。如果你不知道SQL，我可以理解使用Criteria查询，但总的来说，如果我知道我想要什么，我更喜欢HQL。

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

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

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

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

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

标准API

Criteria API更适合动态生成查询。因此，如果您想添加WHERE子句过滤器、JOIN子句，或者改变ORDER BY子句或投影列，Criteria API可以帮助您以一种防止SQL注入攻击的方式动态生成查询。

另一方面，Criteria查询表达能力较差，甚至可能导致非常复杂和低效的SQL查询。

JPQL和HQL

JPQL是JPA标准实体查询语言，而HQL扩展了JPQL并添加了一些特定于hibernate的特性。

JPQL和HQL非常具有表现力，并且类似于SQL。与Criteria API不同，JPQL和HQL可以很容易地预测JPA提供者生成的底层SQL查询。复查HQL查询也比Criteria查询容易得多。

值得注意的是，如果需要修改实体，选择使用JPQL或Criteria API的实体是有意义的。否则，DTO投影是更好的选择。

结论

如果不需要改变实体查询结构，则使用JPQL或HQL。如果需要更改过滤或排序标准或更改投影，则使用criteria API。

然而，仅仅因为您正在使用JPA或Hibernate，这并不意味着您不应该使用本机SQL。SQL查询非常有用，JPQL和Criteria API不是SQL的替代品。