阅读了 Hibernate 的理论后，我多次遇到这样的想法，即在理想情况下，您不应该将 Hibernate 与原始 SQL 查询混合使用，原因有多种，例如 Hibernate 无法识别在此过程中执行的更改正确冲洗时可能会产生影响的方式。
我的任务是尝试优化和改进几个与数据库通信但不通过 Hibernate 的类。他们直接使用 JdbcTemplate 来运行查询，我注意到这更常用于更新语句。
这是经过深思熟虑的良好设计吗，出于某种原因，例如只有选定数量的字段正在更新并且数据库中的对象非常大，或者我应该旨在重构这些类以便它们利用 DAO 层类来执行这些更新查询？
最佳答案
就我个人而言，在使用 hibernate 几年之后(我对它的喜爱多于讨厌)，我看到了当您想仅查询时进行 hibernate 查询的两个主要原因。 可能移动到不同的数据库，查询的缓存将是另一个。对我来说，如果这对您很重要，那么两者都是非常正当的理由。您可能会在这里得到更多答案，为什么这是一件好事，所以我不打算告诉您更多相关信息。相反，我可能会告诉你为什么在我实际遇到的案例中这并不总是可行。
空间查询——几何和地理数据类型；有很多数据库支持这个，有时它是一个非常方便的功能 - 在这方面我真的很喜欢 MSSQL，他们的索引策略，这是如何处理的等等。没有办法在 hibernate 状态下进行这些查询，它有 < em>非常这方面的设施。
Hibernate 有时会隐藏更多它应该隐藏的东西(这不是它的错)；如果您不了解 hibernate 会生成什么查询，您可能常常会感到非常惊讶。我建议您始终检查实际查询。另一个例子是当你使用悲观/乐观锁时 - 总是查看查询，hibernate 并不总是会生成你所期望的结果......(AzureSQL 没有 select for update - 它使用 hints，例如 with row lock 等 - 在没有适当索引和少量资源的情况下，为您提供零保证行将被锁定整个表格或页面可能被锁定)
话虽这么说，但在这方面我总是尽量偏爱 Hibernate，如果某些东西没有按我预期的那样工作 - 我使用 native 查询，恕我直言，这个完美塑造的世界根本不存在。
关于java - 在可能的情况下，是否应该消除 SQL 查询以支持使用 Hibernate？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/52533775/