凌晨两点，告警群突然炸了：订单接口大面积超时，用户投诉说点了几次支付都没反应。我们第一反应是看数据库，结果 MySQL CPU 只有 20%，活跃连接数也不高。很多人到这里会松一口气，觉得数据库没问题。可真相是，接口线程数已经打满，HikariCP 连接池排队超过 200。我是老李，今天就把这次生产 JPA 故障的排查过程完整拆开。为什么现在要讲？因为 Spring Boot + JPA + HikariCP 这套组合太常见了，只看数据库 CPU 往往会错过真正的堵点。

## 01、痛点
生产里 JPA 故障很少以“数据库挂了”这么直白的方式出现。更多时候是接口从 180ms 慢慢涨到 6s，线程池开始堆积，HikariCP 连接数在某个时间点突然打满，随后一批请求出现连接不可用或者超时。与此同时，MySQL 的 CPU 可能只有 20%，没有明显的慢查询告警。这个时候如果只盯着数据库 CPU，会得出“数据库没事，应该是应用问题”的结论。但继续查下去，你会发现应用线程大量阻塞在 HikariCP 获取连接，事务持有连接超过 30s，几条看起来简单的 JPA 查询在 MySQL 端产生了锁等待。

这就是典型的 JPA 故障：它不是单点故障，而是整条调用链的拥堵。痛点不是数据库不会慢，而是我们没有一个从 HTTP 到 MySQL 的排障视角。常见症状可以归为五类：接口变慢、线程堆积、连接池满、SQL 变慢、锁等待。只拿 MySQL CPU 判断，就像只看地铁站入口的人流量，却看不见换乘通道里已经挤成一团。

## 02、是什么
我后来给自己定了一条固定排障链：HTTP → Thread → Transaction → HikariCP → Hibernate → JDBC → MySQL。

一个请求进来，先被 Tomcat 线程接收；Spring Transaction 开启事务；Hibernate 需要执行 SQL 时，从 HikariCP 借连接；连接通过 JDBC 驱动到 MySQL；执行完再归还连接、提交事务、释放线程。这条链上每一层都有自己的指标和等待点。HTTP 层看请求排队和响应时间，Thread 层看线程状态和线程池，Transaction 层看事务开始/结束和持有时间，HikariCP 层看 Active/Pending/Idle 连接和获取连接等待，Hibernate 层看 SQL 生成和缓存，JDBC 层看 Statement 执行，MySQL 层看语句延迟、锁等待和事务。

所谓的端到端诊断，就是沿着这条链逐层收集证据，找到最先堆积的那一层。比如连接池 Pending 升高，说明不是 MySQL 慢，而是连接被占；SQL 延迟升高但 MySQL 正常，说明可能是 JDBC 或 Hibernate 额外开销；MySQL 有锁等待，说明问题在并发事务设计。

## 03、为什么
为什么数据库 CPU 只有 20%，接口仍然可能非常慢？因为 CPU 只是数据库资源的一部分，而接口延迟还包括大量等待时间。数据库不忙，不代表调用链不忙。

我举几个典型场景。第一，连接池排队。HikariCP 默认连接数可能是 10，如果每个事务要 2s，连接池很快被占满，新请求只能等连接。MySQL CPU 可能因为同时执行的事务不多反而很低。第二，长事务。一个事务先查询再调用外部 HTTP 或计算 10s，最后提交。数据库连接和行锁被长时间持有，其他事务只能等。MySQL CPU 不升，但锁等待队列在增长。第三，锁等待。两个事务交叉更新同一组行，行锁或间隙锁互相等待。等待期间 CPU 不消耗，但事务一直挂起。第四，应用线程阻塞。Tomcat 线程池太小或线程饥饿，请求排队，数据库照样空闲。第五，Hibernate 生成的 SQL 有问题，比如 N+1 查询，单次很快，但上千次网络往返累积出几秒延迟。

这些情况有一个共同点：瓶颈不在 MySQL 执行 SQL 的 CPU，而在连接、锁、事务或应用等待。数据库 CPU 低，只能说明数据库没有在执行大量计算，并不能说明接口没有阻塞。

## 04、架构
要看到这条链，需要建立观测点。典型的 Spring Boot 服务可以这样分层采集指标：

| 层 | 关键指标 | 工具 |
| --- | --- | --- |
| HTTP/Thread | Tomcat 活跃线程、排队数、请求耗时 | Actuator / Micrometer |
| Transaction | 事务开始、提交、回滚、最长事务耗时 | 应用埋点 / Spring 事件 |
| HikariCP | Active Connections、Pending Connections、Idle、获取连接等待时间 | Hikari Metrics |
| Hibernate | SQL 条数、语句耗时、缓存命中 | Hibernate Statistics / SQL 日志 |
| JDBC | Statement 执行时间、fetch size | Micrometer 数据源指标 |
| MySQL | SQL 延迟、锁等待、事务、IO、CPU | Performance Schema / sys |

这套架构不是引入新系统，而是把已有的 Actuator、Micrometer、Hikari 指标统一进 Prometheus/Grafana。看板按调用链顺序排布：最上面放 HTTP 和线程，中间放连接池和事务，下面放 SQL 和 MySQL 锁等待。这样当接口变慢时，能一眼看出是请求排队、连接池等待、事务持有过久，还是 MySQL 真实慢。比如某次接口超时，我先看 HTTP TP99 上升，再看 Hikari Pending 上升，然后看 SQL 延迟没有明显变化，MySQL 也没有锁等待，就基本判断是连接池不够或事务范围过大，而不是数据库慢。

## 05、实战
下面我分别制造四类故障，走一遍分析过程。

### 5.1 慢 SQL：全表扫描拖慢整个接口

**制造手段**：在订单列表接口中放一条没有命中索引的查询，比如 `select * from orders where customer_name like '%张%'`，订单表数据量约 800 万行。JPA 里可能写成 `findByCustomerNameContaining`，底层变成全表扫描。

**现象**：接口 TP99 从 200ms 涨到 4s。MySQL CPU 有一定上升，但不高，约 25%。连接池 Active 连接数短暂升高，Pending 开始出现。

**分析过程**：先看 Actuator 的 `/actuator/metrics/http.server.requests`，按 URI 过滤能看到该接口耗时突增。再看 Hikari Metrics，`hikaricp.connections.active` 上升但 `pending` 不高，说明连接不是主要瓶颈。打开 Hibernate SQL 日志，发现这条 `like '%张%'` 语句执行耗时 3.8s。用 MySQL `performance_schema.events_statements_summary_by_digest` 查询该 digest 的平均延迟和扫描行数，发现扫描行数几百万。`EXPLAIN` 显示 `type=ALL`，无索引。

**结论**：这是典型的慢 SQL。数据库 CPU 不高，但全表扫描消耗大量 IO 和行读取，应用线程被拖住。解决方法是加索引或改写查询，而不是先扩容连接池。

### 5.2 连接池耗尽：数据库很闲，接口大面积超时

**制造手段**：在一个支付回调处理里，事务开启后先执行一次 `orderRepository.findById`，然后调用第三方 HTTP 网关，网关响应时间模拟 5s，最后再 `save` 并提交。这个外部调用被放在事务里，事务持有连接长达 5s 以上。

**现象**：接口并发一上来，Tomcat 线程全部等待，HikariCP Active 持续等于最大连接数，Pending 超过 300。MySQL CPU 只有 15%，活跃事务也不多，但每个连接都被事务占着。

**分析过程**：通过 Hikari Metrics 看 `hikaricp.connections.active` 打满，`hikaricp.connections.pending` 暴涨，`hikaricp.connections.timeout` 频繁出现。线程 dump 显示大量线程栈顶为 `HikariPool.getConnection`，等待超时。再结合事务埋点，发现事务平均耗时从 200ms 涨到 6s，说明连接被长事务占用。MySQL 端用 `information_schema.innodb_trx` 能看到多个长时间事务，但 SQL 本身并不慢。

**结论**：连接池耗尽是应用层事务边界问题。把第三方 HTTP 调用移出事务，或者先调用外部服务再开启事务，连接池压力会立刻下降。增加连接池只是临时缓解，不解决连接被长时间占用的根因。

### 5.3 长事务：一条更新被卡了 20 秒

**制造手段**：在一个批量对账任务里，先用 JPA 查询一批订单，然后在应用代码里计算 30s，最后更新这些订单的状态。这个过程放在一个事务里。

**现象**：更新操作的线程堆积，出现 `Lock wait timeout exceeded`。数据库 CPU 不高，但 `information_schema.innodb_trx` 中有一个事务持续了 60s。HikariCP 连接被占住。

**分析过程**：MySQL Performance Schema 的 `events_transactions_current` 能看到事务开始时间；`sys.innodb_lock_waits` 显示有另一条更新在等这个事务持有的行锁。查看 SQL 日志，发现事务先执行 `SELECT`，中间隔了 30s 才执行 `UPDATE`。这时的行锁是在 `SELECT ... FOR UPDATE` 或更新语句后持有的。由于长事务没有提交，其他更新只能等待。

**结论**：长事务不仅占用连接，还会放大锁持有时间。对账计算应该移到事务外，或者分批读取、分批提交。事务只做必要的读写，不要包含任何耗时计算和远程调用。

### 5.4 Lock Wait：两个事务交叉更新

**制造手段**：写两个并发事务，事务 A 先更新表 T 的行 1，再更新行 2；事务 B 先更新行 2，再更新行 1。两个事务几乎同时提交，形成互相等待。也可以使用唯一索引冲突制造间隙锁等待。

**现象**：接口线程卡在 JDBC 执行上，MySQL 出现 `Lock wait timeout exceeded`，或者发生死锁后回滚。CPU 只有 20%，但 `SHOW ENGINE INNODB STATUS` 中有锁等待记录。

**分析过程**：用 MySQL `performance_schema.data_lock_waits` 查看等待关系，能看到哪个事务在等待哪个锁，持有锁的事务是谁。结合 `sys.innodb_lock_waits` 和 `sys.schema_table_lock_waits`，可以还原出两个事务的加锁顺序。应用侧结合 Hibernate SQL 日志，发现两个事务的更新顺序相反，这是并发访问顺序不一致导致的。

**结论**：锁等待不是数据库算力问题，而是并发事务访问顺序和索引设计问题。解决方法是统一更新顺序，减少锁范围，必要时使用乐观锁或缩短事务时间。这类问题只看 CPU 和慢查询完全发现不了。

## 06、洞见
这四个案例串起来，会得到一个更本质的判断：数据访问性能是一整条调用链的问题，而不是数据库单点问题。

数据库 CPU 只是最末端的一个指标，甚至可能是个假阴性信号。真正决定接口体验的，是连接获取延迟、事务持有时间、锁等待和 SQL 访问模式。

我总结了三点。第一，连接池是应用与数据库之间的排队系统，Active/Pending 是两个重要信号。当 Pending 上升时，瓶颈大概率不在 SQL 执行，而在连接归还。第二，事务边界就是性能边界。事务开得越大，连接占用和锁持有就越久，并发吞吐越低。很多 JPA 项目的性能问题，其实是事务里混入了远程调用、消息发送、大对象计算。第三，慢 SQL 要区分“数据库执行慢”和“应用等待慢”。N+1 查询、大结果集映射、缺少批量写，都会让数据库 CPU 看起来不高，但应用端累积出明显延迟。

所以，出问题时不要先问“MySQL 忙不忙”，要先问“线程在哪等、连接被谁占、事务有多长、锁被谁持有”。

## 07、行动
如果只让我做一件事，我会先建立数据库访问 Dashboard，至少观察四类指标：Active/Pending Connections、SQL 延迟、事务耗时、Lock Wait。

- Active/Pending Connections：来自 HikariCP Metrics，看连接池是否排队。
- SQL 延迟：来自 MySQL Performance Schema 的 `events_statements_summary_by_digest` 或应用侧 Statement 指标，看哪些 SQL 变慢。
- 事务耗时：来自 Spring 事务埋点或 MySQL `events_transactions_current`，看长事务。
- Lock Wait：来自 MySQL `data_lock_waits` 和 `sys.innodb_lock_waits`，看锁等待关系。

指标采集可以这样落地：应用侧用 Actuator + Micrometer 暴露 Prometheus 端点，把 HikariCP、Tomcat、数据库连接指标统一接入 Grafana；MySQL 侧用 mysqld_exporter 采集 Performance Schema。

告警阈值建议先宽松后收紧：Hikari Active 超过最大连接数 80% 持续 2 分钟告警，Pending 超过 5 持续 1 分钟告警，SQL TP99 超过 500ms，事务耗时超过 1s，出现 Lock Wait 立即通知。

排查顺序可以固定成一条 checklist：先看 HTTP 和线程，再看 Hikari Pending，然后看事务耗时，最后看 SQL 延迟和 MySQL 锁等待。这个顺序能避免一上来就扎进 SQL 优化，却忽略了连接池和事务这两个隐藏大坑。

## 08、小结
生产 JPA 故障不是数据库单点故障，而是调用链上的拥堵。数据库 CPU 20% 不能证明系统健康，连接池排队、长事务、锁等待都是低 CPU 下可能发生的性能瓶颈。建立 HTTP → Thread → Transaction → HikariCP → Hibernate → JDBC → MySQL 的固定排障链，再配合 Active/Pending Connections、SQL 延迟、事务耗时、Lock Wait 四类指标，能让团队少走很多弯路。

下次接口突然变慢，别再只盯着 MySQL CPU，先看看连接池和事务吧。

## 09、链接与概念说明
- HikariCP：Spring Boot 默认数据库连接池，核心指标包括 Active、Pending、Idle、Connection Timeout。官方文档有详细配置说明。
- JPA/Hibernate：Java 持久化 API 和 ORM 实现，负责实体映射、SQL 生成、事务管理、一级二级缓存。
- Micrometer：JVM 指标门面，可以把 HikariCP、Tomcat、数据源指标暴露给 Prometheus。
- Actuator：Spring Boot 运维端点，提供 `/actuator/metrics` 和 `/actuator/prometheus` 等能力。
- Performance Schema：MySQL 内置性能与等待事件仓库，常用表有 `events_statements_summary_by_digest`、`events_transactions_current`、`data_lock_waits`。
- `sys.innodb_lock_waits`：MySQL 系统库中的锁等待视图，便于快速定位等待关系。
- 推荐延伸阅读：MySQL 官方 Performance Schema 文档、Spring Boot Actuator 官方文档、HikariCP 官方文档、腾讯云开发者社区相关数据库监控文章。

凌晨两点，告警群突然炸了：订单接口大面积超时，用户投诉说点了几次支付都没反应。我们第一反应是看数据库，结果 MySQL CPU 只有 20%，活跃连接数也不高。很多人到这里会松一口气，觉得数据库没问题。可真相是，接口线程数已经打满，HikariCP 连接池排队超过 200。我是老李，今天就把这次生产 JPA 故障的排查过程完整拆开。为什么现在要讲？因为 Spring Boot + JPA + HikariCP 这套组合太常见了，只看数据库 CPU 往往会错过真正的堵点。

《Spring Boot + JPA 实战》第20招 JPA线上怎么排障

通过慢 SQL、连接池耗尽、长事务和锁等待四个实战场景，建立从 HTTP 到 MySQL 的端到端排障链，解释数据库不慢接口为什么还会慢。

架构师

编程语言

数据库

架构设计

生产JPA故障往往不是数据库CPU问题，而是整条调用链的拥堵。本文从HTTP→Thread→Transaction→HikariCP→Hibernate→JDBC→MySQL逐层拆解，分享连接池耗尽、长事务、锁等待、慢SQL四类典型场景的排查方法，教你通过Active/Pending连接数、事务耗时、锁等待等指标快速定位真实瓶颈。

数据库连接池

数据库监控

MySQL

Java

2026上云采购 | AI焕新·智启新局

腾讯云BI特惠9.9元起！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

生产JPA故障往往不是数据库CPU问题，而是整条调用链的拥堵。本文从HTTP→Thread→Transaction→HikariCP→Hibernate→JDBC→MySQL逐层拆解，分享连接池耗尽、长事务、锁等待、慢SQL四类典型场景的排查方法，教你通过Active/Pending连接数、事务耗时、锁等待等指标快速定...

《Spring Boot + JPA 实战》第20招 JPA线上怎么排障-腾讯云开发者社区-腾讯云

《Spring Boot + JPA 实战》第20招 JPA线上怎么排障

《Spring Boot + JPA 实战》第20招 JPA线上怎么排障

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐