Hibernate 中的本机查询性能

Question

很明显hql查询比native慢。正在考虑的项目将使用大量的小交易来执行。所以问题是什么会表现得更好：

• jpa 中的本机查询
• 通过 jdbc 进行本机查询

相差多少？因为 jpa 映射功能和准备好的语句更喜欢它。但是根据性能要求，可能是休眠速度不够快...

编辑

1. 将“要处理的大量数据”替换为“要执行的大量小事务”

Answer 1

这是一种方式你提供的信息太少。

需要处理的大量数据

• 那有多大？就像几百 GB 的几千万条记录？

• 您打算如何处理这些数据？如果您通过 Hibernate（或本机查询或 jdbc）将其拉到 Java 端，那么您可能走错了路。您应该将数据保存在数据库中，并使用数据库提供的工具在其中处理它，并且比任何客户端处理都具有更高的性能。考虑数据库端处理（Oracle 的 PL/SQL，MS SQL Server 的 Transact SQL）。

• 您打算优化什么？数据插入？数据检索？您是否打算使用从大量数据中挖掘的 select 语句？然后考虑在经典 OLTP 之上的 OLAP 解决方案。 OLAP 解决方案构建用于商业智能和通过一些巧妙的技巧分析大量 GB 数据。 Google for it（OLAP、决策立方体）

• 您可以使用底层 SQL 引擎的任何功能吗？例如，如果您使用的是 Oracle，那么您可以在 Hibernate 中实际使用的功能多出 1000 倍。例如，您根本无法在 Hibernate 中进行 Oracle Text 查询，并且确实有很多事情您无法做到。

我可以总结一下，性能差异不在于使用原生 SQL 或 HQL。而是：

• Hibernate 的强大功能在于：处理非常少的数据记录，乐观地将其缓存在 Java 端本地，作为为无法进行数据处理的数据库构建的数据处理系统的基础。 （但仅适用于某些选择、插入、更新、删除）
• 一旦您确实需要移动大量数据，Java 端处理就不是一种选择。正是因为这个原因，80 年代的程序员发明了存储过程。选择一个支持数据库端处理的数据库，以缩短所有网络往返，并在您的 Java 代码中使用 for 循环进行命令式数据处理。而是尽可能多地使用声明性 SQL，并在数据库上运行处理。
• 一旦您即将开始使用数据库的功能，Hibernate 就会成为您的障碍。它实际上是作为 ORM 包装器构建的 - 但是数据处理问题并非一直都是 CRUD 和 ORM 问题。例如，Hibernate 对于 OLAP 用例并不太有用。

大量小额交易

在有大量小事务（向数据库中插入/更新数据）的情况下，Hibernate 没有任何性能优势（因为不能使用 Java 端缓存），而不管数据库正在使用中。但是，您可能更喜欢 hibernate，因为它是将 Java 对象转换为 SQL 语句的好工具。

但是使用 Hibernate，您完全无法控制正在发生的事情。例如，Hibernate + Oracle，向数据库中插入新实体：这是你能想象到的最糟糕的性能噩梦。

这是 Hibernate 所做的：

• 从序列中选择一个新 ID
• 执行一次插入
• 重复无数次

这表现得非常不好。 （序列引用应该是插入语句的一部分，整个插入语句应该使用JDBC批处理。）

我发现在这个特定用例中，基于 JDBC 的方法的运行速度比 Hibernate 快大约 1000 倍。 （预取接下来的 100 个序列，对 Oracle 使用 JDBC Batch 模式，将变量绑定到批处理，以 100 个为一组发送记录，并使用异步提交（这又是您在 Hibernate 中无法控制的）。

我发现如果我想挤出你的大部分工具，我需要深入学习它们。不幸的是，您可以找到许多基于意见的 cmets，尤其是在网络上的 Hibernate 与非 Hibernate 战争中。它们中的大多数是由 Java 开发人员编写的，他们根本不知道幕后发生了什么。所以，不要相信 - 衡量:)