## 01、痛点

凌晨两点，运维群里弹出一条告警：订单服务数据库连接池耗尽，订单列表接口响应时间从200毫秒飙到8秒。开发组的第一反应是“是不是数据库被打满了”，DBA拉出慢SQL一看，没有一条复杂SQL，全是最简单的主键查询，但数量多得吓人——一次分页请求，居然执行了201条SQL。

我是老李，一个在后端和数据库之间来回折腾了十年的程序员。这种场面我并不陌生。代码仓库里，订单查询逻辑只有几行：先查一页订单，再在循环里取客户名称和订单明细数量。Java代码看起来完全正常，单元测试也全过。但一到数据量上来，问题就暴露了。这就是JPA最典型的生产性能问题——N+1。

很多团队用Spring Boot + JPA做业务，功能跑通了，性能却埋在ORM的加载策略里。为什么现在要讲？因为这类问题不会在开发环境出现，却会在生产环境凌晨准时爆炸。它不靠复杂SQL，而是靠SQL数量线性增长，把你的连接池慢慢拖死。

## 02、是什么

N+1，指的是ORM在查询主实体列表时，先发1条SQL拿到N条主记录；随后在访问每条记录的关联属性时，又逐条发SQL，总共需要N+1条甚至更多。

以一个订单列表为例。假设Order关联Customer和OrderItem，两个关联都配置为LAZY。查询100个Order时：

- 第1条SQL：查询100个Order。
- 接下来访问每个Order的customer.getName()，触发100条customer查询。
- 再访问每个Order的items.size()，又触发100条order_item查询。

最终SQL数量是1 + 100 + 100 = 201条。如果页大小是200，SQL就是401条。数据量越大，SQL数量线性增长。

JPA中的LAZY不是不加载，而是延迟到真正访问属性时才加载。Hibernate返回的常常是代理对象，例如CustomerProxy。它看起来像Customer，但内部没有数据；当你调用getName()时，代理对象才向数据库发一条SQL。这个过程被封装得很好，所以开发者常常无感知。

还有个概念要分清：JPA规范里，@ManyToOne和@OneToOne默认是EAGER，@OneToMany和@ManyToMany默认是LAZY。不过为了性能，很多项目会显式把@ManyToOne改成LAZY。问题不在于LAZY本身，而在于加载时机没有被显式管理。

## 03、为什么

N+1之所以泛滥，根因是ORM把“对象导航”变成了“SQL生成”，但开发者看到的是对象，不是SQL。

在数据量小的时候，多几十条SQL完全不敏感。开发环境、测试环境可能只有几十条数据，连接池充裕，日志也没开全。等到生产环境数据量上来，N+1就会从温顺的小问题变成连接池杀手。

一个常见的错误做法是：既然LAZY会触发N+1，那我把所有关联都改成EAGER不就好了？答案是不能。

EAGER看似消除了延迟加载，实际上把“何时加载”和“加载多少”这两个问题混在了一起。如果所有关联都改成EAGER，Hibernate会在主查询里生成大量Join。更危险的是，当多个一对多关联同时EAGER时，会产生笛卡尔积。

举个例子：Order同时EAGER加载items和payments，两个都是一对多。查100个订单，其中每个订单平均4个items、3个payments。Hibernate如果用两个left join，返回行数会接近100×4×3=1200行。如果再加一个一对多关联，行数继续相乘。数据库需要处理巨大的中间结果集，网络传输、内存占用全部膨胀。这不是根治N+1，而是制造更隐蔽的性能炸弹。

所以，解决N+1必须回答两个独立的问题：第一，什么时候加载？第二，加载多少？LAZY和EAGER只回答第一个问题，而且回答得过于粗糙；真正需要的是针对每个接口，设计明确的加载边界和查询形状。

## 04、架构

要理解N+1优化，先看JPA的查询执行链路。

一次查询大致经过：EntityManager -> Session -> PersistenceContext（一级缓存） -> 代理对象 -> JDBC -> 数据库。实体映射中的fetch策略，决定代理对象什么时候发SQL；而查询本身怎么写，决定一次SQL能带回多少数据。

围绕这条链路，有四种常用工具：

**Fetch Join**：在JPQL里使用join fetch，让主实体和关联实体在同一条SQL里加载。它直接初始化关联属性，不再生成代理。适合列表页需要同时展示主表和少数字段的场景。

**EntityGraph**：JPA 2.1提供的抓取图机制。可以在实体或Repository方法上声明一个图，动态覆盖映射里的LAZY/EAGER策略。它比手写join fetch更灵活，尤其适合不同接口对关联字段有不同需求的情况。

**Batch Fetch**：Hibernate的扩展能力。它不把关联都Join到主查询，而是把原本N条逐条ID查询，合并成一条IN查询。例如设置default_batch_fetch_size为100，访问100个customer时只发1条IN查询。它仍然延迟加载，但大幅减少了SQL数量。

**Projection**：只查询DTO或接口投影，不返回托管实体。既然不返回实体，也就没有代理对象和延迟加载，从根源上避免了N+1。它同时解决了“加载多少”的问题。

从架构角度看，Fetch Join和EntityGraph主要解决“何时加载”，Batch Fetch降低延迟加载的次数，Projection则直接减少加载量。实际项目中往往是组合使用，而不是二选一。

## 05、实战

下面用一个Spring Boot + JPA项目模拟真实场景。实体定义如下：

```java
@Entity
public class Order {
  @Id private Long id;

  @ManyToOne(fetch = FetchType.LAZY)
  private Customer customer;

  @OneToMany(mappedBy = "order", fetch = FetchType.LAZY)
  private List<OrderItem> items;
}
```

Customer和OrderItem略过，只需要知道Order.customer是ManyToOne，Order.items是OneToMany。

**第一版：故意产生200+ SQL**

```java
List<Order> orders = orderRepository.findAll(pageable).getContent(); // 1条SQL
for (Order order : orders) {
    order.getCustomer().getName();   // 每个订单1条，共100条
    order.getItems().size();         // 每个订单1条，共100条
}
```

访问100个Order，最终SQL数1 + 100 + 100 = 201。这就是典型的N+1。

**优化一：Fetch Join**

```java
@Query("select distinct o from Order o " +
       "join fetch o.customer c " +
       "left join fetch o.items i")
List<Order> findAllWithDetails();
```

这里用distinct是因为left join fetch一对多集合会让根实体重复。经过这条JPQL，主查询和两个关联都被加载进同一个结果集，SQL数量降到1条。但如果关联集合很大，结果集行数会膨胀，需要结合业务判断。

**优化二：EntityGraph**

```java
@EntityGraph(attributePaths = {"customer", "items"})
@Query("select o from Order o")
List<Order> findAllWithGraph();
```

EntityGraph会覆盖实体上的LAZY设置，按图加载customer和items。对于包含一个ManyToOne和一个OneToMany的情况，Hibernate通常能在少量SQL内完成加载，不再逐条查询。它的好处是，当多个接口需要不同关联字段时，可以在方法上声明不同的图，而不是写死join fetch。

**优化三：Projection**

如果订单列表页根本不展示完整items，只需要客户名和明细数量，使用投影更合适：

```java
public interface OrderProjection {
    Long getId();
    String getCustomerName();
    Long getItemCount();
}
```

```java
@Query("select o.id as id, c.name as customerName, " +
       "(select count(i) from OrderItem i where i.order = o) as itemCount " +
       "from Order o join o.customer c")
List<OrderProjection> findOrderProjections();
```

这条查询只返回列表页需要的三列，不要托管实体，也不存在代理对象。SQL数量稳定在1条，而且查询结果集比实体小得多。

另外，如果不想改代码，可以先配置Batch Fetch：

```yaml
spring:
  jpa:
    properties:
      hibernate.default_batch_fetch_size: 100
```

这样第一版代码中100个customer加载会合并成1条IN查询，100个items加载也合并成1条IN查询，总SQL数从201降到3。它不能替代查询设计，但适合作为快速止血手段。

## 06、洞见

JPA最大的性能危险，不是SQL写错，而是开发者根本不知道执行了多少条SQL。

我们写代码时，眼睛盯的是Java对象和业务逻辑；数据库中实际执行的SQL，往往要等到出了问题才去翻日志。很多团队甚至没有开启SQL日志。换句话说，N+1可能已经在生产环境跑了几个月，只是数据量还没到临界点。

把关联全部改为EAGER，就是在这种“看不见SQL”的状态下做出的拍脑袋决定。它可能让SQL数量变少，但单条SQL的复杂度急剧上升。多个一对多关联EAGER会让数据库Join出巨大中间结果，甚至出现笛卡尔积。表面上接口慢了，SQL少了，实际上数据库消耗更大，调优更难。

所以，判断JPA性能不能只看响应时间，还要看SQL数量和查询形状。每一条查询都要有预算：这个接口允许几条SQL？返回多少行？关联哪些字段？只有把SQL计数显性化，才能避免被ORM的便利性反噬。

## 07、行动

给关键接口增加SQL Count测试，把查询次数纳入验收。

具体做法是，在测试环境启用Hibernate Statistics，执行接口后断言SQL数量不超过预算。比如订单列表接口，预算设为5条；如果某次改动把SQL数量从3条拉到201条，测试立刻失败。

示例：

```java
@SpringBootTest
@AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE)
class OrderApiSqlCountTest {

  @Autowired
  private SessionFactory sessionFactory;

  @Test
  void orderListShouldNotTriggerNPlusOne() throws Exception {
      sessionFactory.getStatistics().clear();

      mockMvc.perform(get("/orders?page=0&size=100"))
             .andExpect(status().isOk());

      long sqlCount = sessionFactory.getStatistics().getPrepareStatementCount();
      assertThat(sqlCount).isLessThanOrEqualTo(5);
  }
}
```

需要开启`hibernate.generate_statistics=true`。如果不想用Hibernate Statistics，也可以用datasource-proxy或p6spy在数据源层统计SQL，逻辑类似。

把SQL Count测试放进CI流水线，和单元测试一起跑。任何人对查询逻辑、实体映射、Repository做了改动，只要SQL数量超标，构建就失败。这样N+1就不再有潜伏机会。

除此之外，生产环境还应打开慢SQL日志，定期检查SQL数量异常接口。对关键列表、详情接口建立性能基线，查询次数和响应时间一起监控。

## 08、小结

N+1不是JPA的Bug，而是加载策略和查询边界不清晰的结果。它的本质是：开发者用对象思维写代码，却没有管理对象背后的SQL。

解决思路也很清晰：

- 用Fetch Join或EntityGraph管理“何时加载”；
- 用Projection管理“加载多少”；
- 用Batch Fetch快速降低延迟加载产生的SQL次数；
- 别把所有关联改成EAGER，那只会制造新的灾难；
- 最后，用SQL Count测试守住底线。

下次写JPA查询时，不妨先问自己一句：这个接口，到底应该执行几条SQL？

## 09、链接与概念说明

**概念说明**

- **N+1查询**：先查询N条主数据，再对每条数据逐条查询关联，导致SQL数量线性增长。
- **LAZY / EAGER**：JPA的加载时机策略。LAZY延迟到属性访问时加载，EAGER立即加载。
- **Proxy**：Hibernate为延迟加载生成的代理对象，未初始化时访问属性会触发SQL。
- **Fetch Join**：JPQL的join fetch子句，在一条SQL中初始化关联实体。
- **EntityGraph**：JPA抓取图，可覆盖实体映射中的fetch策略。
- **Batch Fetch**：Hibernate批量抓取机制，将多条单个ID查询合并为IN查询。
- **Projection**：只查询DTO或接口投影，不返回托管实体。
- **笛卡尔积**：多个一对多关联同时Join时行数相乘，导致结果集膨胀。

**参考链接**

- JPA 2.2 规范：https://jakarta.ee/specifications/persistence/2.2/
- Hibernate官方文档：https://hibernate.org/orm/documentation/
- Spring Data JPA参考：https://docs.spring.io/spring-data/jpa/docs/current/reference/html/
- Hibernate Statistics说明：https://docs.jboss.org/hibernate/orm/current/userguide/html_single/Hibernate_User_Guide.html#statistics

凌晨两点，运维群里弹出一条告警：订单服务数据库连接池耗尽，订单列表接口响应时间从200毫秒飙到8秒。开发组的第一反应是“是不是数据库被打满了”，DBA拉出慢SQL一看，没有一条复杂SQL，全是最简单的主键查询，但数量多得吓人——一次分页请求，居然执行了201条SQL。

《Spring Boot + JPA 实战》第9招 N+1怎么治

从100个订单触发200多条SQL说起，讲清JPA N+1成因、优化手段与查询次数验收方法。

架构师

后端

数据库

编程语言

JPA项目在高并发下遭遇N+1查询，导致连接池耗尽、响应时间飙升。本文深度解析N+1问题根因，对比Fetch Join、EntityGraph、Projection、BatchFetch四种优化方案，提供实战代码与SQL计数测试方法，助你构建高性能Spring Boot应用。

数据库连接池

单元测试

代码解释

Java

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《Spring Boot + JPA 实战》第9招 N+1怎么治-腾讯云开发者社区-腾讯云

《Spring Boot + JPA 实战》第9招 N+1怎么治

《Spring Boot + JPA 实战》第9招 N+1怎么治

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐