jpa并未让开发者彻底告别sql，而是通过封装sql提升了开发效率；2. jpa通过实体映射、entitymanager、jpql、criteria api和原生sql查询等机制实现对象与数据库的交互；3. jpql适用于简单、固定的查询，具有良好的可读性，但缺乏编译时检查；4. criteria api适用于动态、复杂的查询，提供类型安全和编程灵活性，但代码量较大；5. 当性能优化、使用数据库特有功能、批量操作、调用存储过程或进行复杂etl时，应选择原生sql；6. 使用原生sql需注意可移植性降低、类型安全缺失、sql注入风险、缓存失效及维护成本增加等问题；7. 掌握sql仍是开发者必备技能，jpa是高效工具，但在其力不从及时，sql提供强有力的补充手段，两者应结合使用以实现最佳效果。
JPA（Java Persistence API）规范本质上是Java应用程序与关系型数据库之间的一座桥梁，它允许我们用面向对象的方式来操作数据，而JPA框架（如Hibernate、EclipseLink）则在底层负责将这些对象操作翻译成具体的SQL语句，并执行到数据库中。这意味着，虽然我们日常编码中可能直接与SQL打交道的时间变少了，但SQL依然是驱动数据库操作的核心语言，JPA只是为我们提供了一个更高级、更便捷的抽象层。
解决方案
JPA通过一系列机制实现了对SQL的封装和操作：
-
实体映射（Entity Mapping）：这是JPA的基础。我们通过注解（如
@Entity
,@Table
,@Column
,@Id
等）或XML配置，将Java类映射到数据库表，将类的属性映射到表的列。JPA框架在运行时会读取这些映射信息，从而知道如何将Java对象的数据存入或取出数据库。 -
EntityManager：这是JPA的核心API接口，它负责管理实体（Java对象）的生命周期，包括持久化（保存）、查找、更新和删除。当我们调用
entityManager.persist(entity)
时，JPA会根据实体映射生成相应的INSERT
SQL语句；调用entityManager.find(Class, id)
时，会生成SELECT
SQL语句；entityManager.merge(entity)
对应UPDATE
或INSERT
；entityManager.remove(entity)
则生成DELETE
。 -
JPQL (Java Persistence Query Language)：JPA提供了一种面向对象的查询语言JPQL，它与SQL语法相似，但操作的是实体对象及其属性，而不是数据库表和列。例如，
SELECT u FROM User u WHERE u.age > 30
。JPA框架会将这条JPQL语句解析并翻译成针对具体数据库的SQL查询。这极大地提高了查询的可移植性，因为我们无需关心不同数据库的SQL方言差异。 - Criteria API：对于更复杂的、动态构建的查询，JPA提供了Criteria API。这是一套类型安全的、编程方式的API，允许我们通过Java代码来构建查询语句。虽然代码量可能比JPQL多一些，但它提供了编译时类型检查，减少了运行时错误，并且在构建复杂条件时表现出强大的灵活性。
-
原生SQL查询（Native SQL Queries）：尽管JPA致力于抽象SQL，但它也提供了执行原生SQL查询的能力。当我们需要利用数据库特有的功能、优化特定查询性能、或者处理JPA难以表达的复杂逻辑时，可以直接通过
entityManager.createNativeQuery()
来执行原始的SQL语句。
JPA真的能让开发者彻底告别SQL吗？理解其底层机制与限制
我个人觉得，说JPA能让开发者彻底告别SQL，这多少有点言过其实了。JPA确实极大地降低了我们直接编写SQL的频率，尤其是在处理常规的CRUD操作时，它简直是效率神器。但它更像是一个智能翻译官，而不是一个能完全替代原语言的存在。
立即学习“Java免费学习笔记（深入）”；
从底层机制来看，JPA框架（比如Hibernate）在运行时会根据我们的实体映射和JPQL/Criteria API查询，生成并执行具体的SQL语句。你可以通过配置日志，清楚地看到JPA在背后默默地输出了哪些SQL。所以，SQL始终在那里，它只是被JPA封装起来了。
这种封装带来了巨大的便利：跨数据库兼容性、对象化操作、缓存管理、事务支持等等。但它也有局限性。比如，当你遇到一个性能瓶颈，或者需要编写一个非常复杂的报表查询，涉及多张表的大量联接、聚合函数，甚至需要利用数据库特定的窗口函数或者存储过程时，JPA的JPQL或Criteria API可能就显得力不从心了，或者生成的SQL效率不高。这时候，有经验的开发者往往会选择直接编写原生SQL，甚至结合数据库的执行计划（explain plan）进行优化。
所以，我的观点是：JPA是我们的主要工具，它负责了大部分的“体力活”，但掌握SQL依然是后端开发者的基本功，它能帮助我们理解JPA生成的SQL是否合理，也能在JPA无法满足需求时，提供“降维打击”的解决方案。
JPA的两种主要查询方式：JPQL与Criteria API的实战应用
在JPA的世界里，除了通过
EntityManager的
find方法按ID查询，我们最常用的就是JPQL和Criteria API这两种查询方式了。它们各有千秋，适用于不同的场景。
JPQL（Java Persistence Query Language）
JPQL是一种非常直观的查询语言，它的语法和SQL很像，但操作的是实体类和它们的属性。比如，我们想查询所有年龄大于25岁的用户：
// JPQL 示例
String jpql = "SELECT u FROM User u WHERE u.age > :minAge";
List<User> users = entityManager.createQuery(jpql, User.class)
.setParameter("minAge", 25)
.getResultList();JPQL的优势在于其简洁性和可读性，对于简单的查询，写起来非常顺手，就像写SQL一样自然。但它的缺点是，查询字符串是普通的Java字符串，这意味着任何语法错误都只能在运行时才能发现，缺乏编译时检查。当查询逻辑变得复杂，或者需要根据不同条件动态拼接查询时，字符串操作会变得非常繁琐且容易出错。
Criteria API
Criteria API则提供了一种完全编程化的方式来构建查询。它通过一系列Java对象和方法调用来表示查询的各个部分，比如选择（select）、条件（where）、排序（orderBy）等。
// Criteria API 示例
CriteriaBuilder cb = entityManager.getCriteriaBuilder();
CriteriaQuery<User> cq = cb.createQuery(User.class);
Root<User> user = cq.from(User.class);
cq.select(user).where(cb.greaterThan(user.get("age"), 25));
List<User> users = entityManager.createQuery(cq).getResultList();Criteria API的优点是显而易见的：类型安全。所有的查询构建都在编译时进行，任何属性名拼写错误、类型不匹配等问题都会立即被IDE发现，大大减少了运行时错误。此外，它在动态查询构建方面表现出色，可以轻松地根据条件添加或移除查询子句。不过，它的缺点是代码量相对较大，对于简单的查询来说，可能会显得有些啰嗦，可读性也不如JPQL直观。
实战中，我通常会这样选择：对于固定、简单的查询，我会优先选择JPQL，因为它写起来更快、更简洁。而对于那些需要根据用户输入动态构建查询条件，或者查询逻辑本身就比较复杂的场景，Criteria API则是我更倾向的选择，它的类型安全和编程灵活性能够避免很多潜在的坑。
当JPA力不从心时：何时选择原生SQL查询及注意事项
即便JPA功能强大，也总有那么些时候，我们不得不“放下身段”，直接与原生SQL打交道。这并非JPA的失败，而是任何抽象层都无法百分百覆盖底层所有细节的必然结果。
选择原生SQL的常见场景：
- 性能优化：这是最常见的原因。JPA生成的SQL在大多数情况下是高效的，但对于某些极度复杂的查询（比如涉及大量联接、子查询、或者需要特定索引提示的报表查询），JPA生成的SQL可能不是最优的。这时候，一个精心手写的原生SQL往往能带来显著的性能提升。
-
数据库特定功能：不同的数据库系统（MySQL、PostgreSQL、Oracle等）都有其独特的函数、语法或特性（如MySQL的
GROUP_CONCAT
、PostgreSQL的JSONB
操作符、Oracle的CONNECT BY
）。JPA的JPQL和Criteria API通常只支持ANSI SQL标准，无法直接利用这些数据库特有的功能。 -
批量操作：JPA的
persist
/merge
/remove
操作通常是针对单个实体进行的，即便有批量插入/更新的优化（如JDBC批处理），但对于大规模的数据导入或更新，直接执行INSERT INTO ... SELECT FROM ...
或UPDATE ... WHERE ...
这样的原生SQL语句，效率往往更高。 - 存储过程/函数调用：如果业务逻辑封装在数据库的存储过程或函数中，那么直接通过JPA调用这些原生过程是必要的。
- 复杂的数据迁移/ETL：在进行数据清洗、转换、加载（ETL）等操作时，原生SQL的灵活性和强大功能是JPA难以比拟的。
如何在JPA中执行原生SQL：
JPA提供了
entityManager.createNativeQuery()方法来执行原生SQL。
// 执行一个返回实体的原生SQL查询
Query query = entityManager.createNativeQuery("SELECT * FROM users WHERE status = ?", User.class);
query.setParameter(1, "active");
List<User> activeUsers = query.getResultList();
// 执行一个返回标量值（非实体）的原生SQL查询
Query countQuery = entityManager.createNativeQuery("SELECT COUNT(*) FROM products WHERE price > ?");
countQuery.setParameter(1, 100.0);
Long productCount = ((Number) countQuery.getSingleResult()).longValue();
// 执行更新/删除的原生SQL
int updatedRows = entityManager.createNativeQuery("UPDATE orders SET status = 'cancelled' WHERE id = ?")
.setParameter(1, orderId)
.executeUpdate();注意事项：
- 可移植性降低：原生SQL是数据库特定的，这意味着你的应用程序可能不再是“一次编写，到处运行”了。如果将来更换数据库，可能需要重写这些原生SQL。
- 类型安全缺失：与JPQL和Criteria API不同，原生SQL查询在编译时没有类型检查。任何列名拼写错误、类型不匹配都可能导致运行时错误。
-
SQL注入风险：如果原生SQL查询中包含用户输入，务必使用参数绑定（
setParameter
），而不是直接拼接字符串，以防止SQL注入攻击。 - 缓存与事务管理：JPA的二级缓存通常不会对原生SQL查询的结果生效。此外，原生SQL操作同样需要纳入JPA的事务管理体系中。
- 维护成本：相比JPA的面向对象操作，原生SQL的可读性和维护成本可能会更高，尤其是在团队协作时。
总的来说，原生SQL是JPA的有力补充，是解决特定问题时的“杀手锏”。但它应该被视为一种高级工具，在明确了解其利弊和风险的前提下，谨慎而有策略地使用。
