hql和criteriaApi和QueryOver之间的性能有什么区别？是否存在一种比另一种更快或更慢的情况？
编辑：我用 QueryOver 和 Linq 扩展了这个问题。
==============================================
好吧，我不确定将哪个回复标记为答案，所以我会标记大多数 VoteUp 的帖子。我不知道。这实际上是更多的讨论而不是一个问题。
【问题讨论】：
标签： performance nhibernate criteria icriteria
ICriteria 和 HQL 之间的性能特征略有不同（我不知道 QueryOver），原因很简单。
ICriteria 查询将默认尝试实现映射中定义的获取策略，而 HQL 默认情况下会考虑所有内容 Lazy 并取决于查询中的连接声明来定义急切获取或不获取的内容。
此外，ICriteria 依赖于参数传递的映射，而 HQL 允许显式参数类型，例如IQuery.SetInt32("fooParam", 5);
真正重要的是 ICriteria 查询的可插入性（请参阅 ICriteria.CreateCriteria().CreateCriteria() 等），其中 NH 引擎必须解析 ICriteria 并尝试生成最有效的 SQL。
另一方面，它可能更容易预测 HQL 查询是否会产生一致的结果，从而使 QueryCache 的使用更容易。
无论哪种方式，配置都是通过 ISessionFactory 创建和映射定义生成一次，而其他东西都在内存中，因此性能很好。
两者之间的实际 SQL 生成方式不同，这就是不存在用于 ICriteria -> HQL 的实用程序的原因。
最后，我的经验告诉我，两者之间的性能可能相同或需要几毫秒。
作为附注，在映射中尽可能多地声明将导致更简洁的 sql 生成以及 NHibernate 操作，例如对于映射 .hbm.xml 中的Length 的字符串属性将导致 NHibernate 检查进入数据库之前的字符串长度。
【讨论】：
就 QueryOver 而言，我希望其性能与 Criteria API 相同，因为它是作为该 API 的扩展而构建的。因此，对于两个 API 中的等效查询，我希望生成相同的数据库查询。我注意到 QueryOver 和 Criteria 接口之间的唯一区别是我发现 QueryOver 接口“更干净”并且使用起来更愉快。
根据我的经验，Criteria API 比 HQL 接口更受“喜爱”。我遇到过一些情况，我可以使用条件接口来表达某些查询，而我在 HQL 接口中找不到等效的表达方式。
关于性能，我发现“询问”查询的方式比选择 Criteria API 与 HQL 与 QueryOver 对性能的影响更大。我会使用最符合您想法的界面。
【讨论】：
QueryOver 在大多数方面都是 Criteria 的一个很好的替代品，因为它改进了语法和类型安全。但是，应该注意的是，在 QueryOver 可能 中处理 lambda 表达式会很昂贵（我想这同样适用于 LINQ 查询）。因此，虽然执行结束 SQL 查询不会比其他方法（ICriteria、HQL）花费更长的时间，但将查询对象转换为适当的 SQL 查询确实需要更长的时间。
例如，我们一直在开发一个每秒运行数百个 QueryOver 查询的应用程序（使用 ADO.NET 批处理支持），我们发现将查询转换为 ICriteria 几乎使我们执行查询的能力增加了一倍，并将 CPU 使用率减半.我想如果你使用二级缓存和查询缓存，处理 lambda 表达式的开销会大大减少；但是由于这不适合我们的应用程序，我自己没有这样做。
关于您更一般的问题，即哪个更快：这真的取决于。唯一可靠的方法是运行分析工具（NHProf 可以在这种情况下创造奇迹）。但一般来说，HQL 是最接近 SQL 的，因此也是最灵活的，允许您有更多的空间来优化您的查询。但是，对于绝大多数简单到中等复杂度的查询，ICriteria 和 HQL 之间几乎没有区别。如果您的查询是动态构建的，那么 ICriteria 查询会更容易处理。
【讨论】：
我还没有找到两者之间的任何区别。话虽如此 - hql 具有 Criteria-API 中不可用的功能。
如果您使用前者还是后者，这主要取决于风格和个人喜好。在查询方面，从查询到 SQL 的转换并不占太多。
来自比我更了解的人：http://ayende.com/Blog/archive/2009/06/01/nhibernate-queries-ndash-should-i-use-hql-or-criteria.aspx
【讨论】：