我对何时以及何时不使用JPA 2.0中的 native 查询感到非常困惑。我的印象是，使用 native 查询可能会使我与JPA缓存不同步。如果我可以使用JPQL或CriteriaBuilder查询完成同一件事，那么是否有充分的理由使用 native 查询？同样，如果我可以使用JPQL或CriteriaBuilder完成相同的操作，则使用 native 查询是否存在任何危险？最后，如果使用 native 查询存在与JPA缓存不同步的危险，那么在使用JPQL或CriteriaBuilder执行等效查询时会存在同样的危险吗？
我的原则是避免本地查询，但是肯定有必要这样做。在我看来，如果我可以使用JPQL或CriteriaBuilder做到这一点，那么我应该这样做。
谢谢。
最佳答案
我同意你的哲学。
native 查询的主要问题恕我直言，是可维护性。首先，它们通常比JPQL查询更复杂且更长。但是它们也对表和列名进行硬编码，而不是使用类和属性名。
JPQL查询在重构时已经存在问题，因为它们在字符串中硬编码类和属性名称。但是 native 查询甚至更糟，因为它们在各处硬编码表名和列名。
我认为 native 选择查询不是关于缓存的问题。但是， native 更新，插入和删除查询是一个问题，因为它们会在第一级和第二级缓存的后面修改数据。因此，这些可能会过时。
另一个问题是， native 查询可能使用一种数据库可以识别的语法，而另一数据库却不能，因此使应用程序很难从一个数据库迁移到另一个数据库。
关于jpa-2.0 - 一个人什么时候应该在JPA 2.0而不是JPQL或CriteriaBuilder上使用 native 查询？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9546806/