Spring Data JPA 查询慢？教你获取 MySQL EXPLAIN 分析

2025-04-27 06:56:34

Spring Data JPA 查询 MySQL：如何加上 EXPLAIN 分析性能

用 Spring Data JPA 操作 MySQL 时，碰上大数据量（几百万、上千万甚至上亿行）的查询，性能慢是常有的事儿。尤其是用了 Specifications 做动态过滤，再加上 Pageable 分页，心里就更没底了：这查询到底走了索引没？走的哪个索引？要是没走，那全表扫描岂不是要慢死？

这时候，自然会想到 MySQL 的 EXPLAIN 命令。它能告诉你 MySQL 打算怎么执行这条 SQL，用了哪个索引，扫描了多少行等等，是性能分析的利器。

可问题来了：Spring Data JPA 把具体的 SQL 都封装起来了，咱们直接打交道的都是 Java 对象和方法，比如 JpaRepository 的接口、Specification 对象。怎么才能方便地在 JPA 生成的 SQL 前面加上 EXPLAIN 呢？

为啥直接加 EXPLAIN 这么难？

主要是因为 JPA（以及它背后的实现，比如 Hibernate）的抽象层。你写的 Specification 或者调用的 findByXXX 方法，在运行时会被 JPA 框架动态地转换成 SQL 语句。这个转换过程考虑了你的实体映射、关联关系、传入的参数、分页信息等等。

你想拿到这个最终生成的、带具体参数值的 SQL，并把它交给 EXPLAIN 去分析，并不是 JPA 的标准功能。JPA 关心的是帮你屏蔽数据库差异，简化数据访问，而不是直接暴露底层 SQL 的执行计划细节。所以，没有一个像 .explain() 这样简单直接的方法。

解决办法：让 EXPLAIN 现形！

虽然没有一键 EXPLAIN 的功能，但咱们可以曲线救国。下面介绍几种常用的方法，让你能看到 JPA 查询对应的 EXPLAIN 结果。

方法一：JPA/Hibernate 日志大法

这是最容易上手的方法。通过配置 JPA 或者 Hibernate 的日志级别，让它在控制台或者日志文件里打印出实际执行的 SQL 语句。

原理和作用：

设置特定的日志配置项后，JPA 提供者（通常是 Hibernate）在执行数据库查询前，会把生成的 SQL 语句输出到日志中。你拿到这个 SQL 后，就可以手动去 MySQL 客户端（比如 MySQL Workbench、DBeaver 或者命令行）执行 EXPLAIN <你的 SQL 语句> 了。

操作步骤 (application.properties 或 application.yml)：

对于 application.properties:

# 让 Hibernate 显示它执行的 SQL
spring.jpa.show-sql=true
# 对 SQL 进行格式化，方便阅读
spring.jpa.properties.hibernate.format_sql=true
# (可选) 在日志中显示 SQL 绑定的参数值，需要将日志级别调到 TRACE
logging.level.org.hibernate.type.descriptor.sql=TRACE

对于 application.yml:

spring:
  jpa:
    # 显示 SQL
    show-sql: true
    properties:
      hibernate:
        # 格式化 SQL
        format_sql: true
# (可选) 显示参数绑定日志
logging:
  level:
    org:
      hibernate:
        type:
          descriptor:
            sql: TRACE # TRACE 级别会输出参数值

怎么用 EXPLAIN？

运行你的 Spring Boot 应用，并触发那个你怀疑有性能问题的查询（比如调用对应的 Repository 方法）。
观察控制台或日志文件，找到 Hibernate 输出的 SQL 语句。如果配置了 TRACE 级别的日志，你还能看到 binding parameter [1] as [VARCHAR] - [具体的值] 这样的信息。
复制这条完整的 SQL 语句。注意： 如果有参数占位符 ?，并且你没有开 TRACE 日志，你需要根据代码逻辑手动把 ? 替换成实际的参数值。开了 TRACE 日志会方便很多，可以直接用日志里显示的值。
打开你的 MySQL 客户端，连接到对应的数据库。
粘贴 SQL 语句，并在前面加上 EXPLAIN，像这样： EXPLAIN SELECT ... FROM your_table WHERE ...;
执行！查看输出的执行计划。

安全建议：

show-sql=true 和 TRACE 级别的日志会暴露 SQL 语句和参数，在生产环境中要慎用。它们可能会泄露敏感信息，并且产生大量日志影响性能。最好只在开发和测试环境中使用。如果生产环境需要诊断，临时开启，用完即关，并注意脱敏。

进阶使用技巧：

TRACE 级别的日志量可能非常大，尤其是在高并发场景下。你可以更精确地只针对特定的包或类开启 TRACE，例如只看参数绑定：logging.level.org.hibernate.type.descriptor.sql=TRACE。
结合 Spring Boot Actuator 的 /loggers 端点，可以在运行时动态调整日志级别，而无需重启应用，方便临时诊断。

方法二：祭出 P6Spy 神器

如果觉得手动从日志里拼 SQL 还是有点麻烦，或者想更准确地捕获带参数值的 SQL，可以试试 P6Spy。

原理和作用：

P6Spy 是一个 JDBC 驱动代理。它把自己伪装成一个 JDBC 驱动，夹在你应用和实际的数据库驱动之间。所有经过它的 JDBC 调用（包括 SQL 语句和参数）都会被它拦截并记录下来。P6Spy 可以非常精确地记录下最终发送给数据库的 SQL，包括所有参数值。

操作步骤：

添加依赖： 在你的 pom.xml (Maven) 或 build.gradle (Gradle) 文件中加入 P6Spy 的依赖。

<!-- pom.xml -->
<dependency>
    <groupId>p6spy</groupId>
    <artifactId>p6spy</artifactId>
    <version>3.9.1</version> <!-- 使用最新稳定版 -->
</dependency>

配置 P6Spy： 在 src/main/resources 目录下创建一个 spy.properties 文件。

# 指定 P6Spy 记录日志的方式，默认是 slf4j
# 如果你的项目用了 slf4j (Spring Boot 默认自带), 这个可以不用显式配，或者配成 logback
# logback=com.p6spy.engine.logging.P6LogFactory
# modulelist=com.p6spy.engine.spy.P6SpyFactory,com.p6spy.engine.logging.P6LogFactory

# 日志输出格式，可以定制
# 例如，只输出执行时间和SQL（带参数）
logMessageFormat=com.p6spy.engine.spy.appender.CustomLineFormat
customLogMessageFormat=took %(executionTime) ms | %(sqlsingleline)

# 配置真实的数据库驱动类名
# (如果你没有用下面的URL修改方式，可能需要这个，但URL方式更常用)
# realdriver=com.mysql.cj.jdbc.Driver

# 配置日志文件路径 (可选，默认输出到控制台或SLF4J配置的地方)
# logfile=/path/to/your/p6spy.log
# append=true

修改 JDBC URL： 这是关键一步。你需要修改 application.properties 或 application.yml 中的数据库连接 URL，在原来的 JDBC URL 前面加上 p6spy: 前缀。

# application.properties 示例
# 原来的 URL: spring.datasource.url=jdbc:mysql://localhost:3306/mydb?serverTimezone=UTC
# 修改后的 URL:
spring.datasource.url=jdbc:p6spy:mysql://localhost:3306/mydb?serverTimezone=UTC

# 不需要再指定 driver-class-name，p6spy 会自动代理
# spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver # 注释掉或删掉这行

# application.yml 示例
spring:
  datasource:
    # 原来的 URL: jdbc:mysql://localhost:3306/mydb?serverTimezone=UTC
    # 修改后的 URL:
    url: jdbc:p6spy:mysql://localhost:3306/mydb?serverTimezone=UTC
    # driver-class-name: com.mysql.cj.jdbc.Driver # 注释掉或删掉这行

怎么用 EXPLAIN？

启动应用，执行查询。
P6Spy 会根据 spy.properties 的配置，将拦截到的 SQL 语句（已经填充了参数值）输出到控制台或日志文件。
复制这条 SQL 语句。
到 MySQL 客户端，前面加上 EXPLAIN 执行。

安全建议：

同样，P6Spy 记录的日志包含完整的 SQL 和参数，生产环境慎用。它的性能开销比单纯的 Hibernate 日志略高，因为它做了一层代理。

进阶使用技巧：

P6Spy 非常灵活，spy.properties 里有很多配置项，可以控制日志格式、输出目标、是否记录慢查询等。
可以结合 Logback 或 Log4j2 的配置，将 P6Spy 的日志输出到单独的文件，或者根据执行时间过滤日志。

方法三：原生查询 + 手动 EXPLAIN

如果某个特定的查询总是很慢，而且你知道它大概会生成什么样的 SQL 结构，可以尝试直接用原生查询（Native Query）来执行 EXPLAIN。

原理和作用：

Spring Data JPA 支持执行原生的 SQL 语句。你可以直接在 @Query 注解里写 EXPLAIN SELECT ... 语句。但这种方法有局限性，它得到的结果是 EXPLAIN 的输出内容（通常是多行多列的文本信息），而不是查询本身的数据结果。这通常用于调试和分析，不太适合直接在业务代码里用。

操作步骤：

在 Repository 接口中定义一个方法：

import org.springframework.data.jpa.repository.JpaRepository;
import org.springframework.data.jpa.repository.Query;
import java.util.List;

public interface YourEntityRepository extends JpaRepository<YourEntity, Long> {

    // 注意：你需要知道或者猜测 Hibernate 可能生成的 SQL 是什么样的
    // 这里的 SQL 需要你自己根据实际情况写，可能包含 JOIN 等
    // 参数可以通过 :paramName 的方式传入
    @Query(value = "EXPLAIN SELECT * FROM your_entity WHERE some_column = :value AND another_column = :anotherValue", nativeQuery = true)
    List<Object[]> explainFindBySomeColumnAndAnotherColumn(String value, String anotherValue);

    // 也可以 EXPLAIN 一个不带参数的查询
    @Query(value = "EXPLAIN SELECT * FROM your_entity WHERE status = 'ACTIVE'", nativeQuery = true)
    List<Object[]> explainFindActiveEntities();

    // 返回值通常是 List<Object[]> 或 List<String>，因为 EXPLAIN 的结果结构是固定的文本表格
    // 解析这个结果可能需要额外的代码
}

调用这个方法：

List<Object[]> explainResult = yourEntityRepository.explainFindBySomeColumnAndAnotherColumn("some_test_value", "another_test_value");

// 打印 EXPLAIN 的输出结果
for (Object[] row : explainResult) {
    System.out.println(java.util.Arrays.toString(row));
}

怎么用 EXPLAIN？

这种方法直接在 Java 代码里就“执行”了 EXPLAIN。你需要处理返回的 List<Object[]>（或其他类型），解析每一行每一列的含义，这等同于你在 MySQL 客户端看到的结果。

注意事项：

你写的原生 EXPLAIN 语句里的 SQL 部分，必须尽可能地接近 Hibernate 实际生成的 SQL，否则分析结果可能不准确。这对于复杂的 Specification 组合来说可能很困难。
这种方式的主要目的是在代码层面快速查看某个特定原生查询的执行计划，对于动态生成的查询（如通过 Specification）就不太适用了。
解析 EXPLAIN 的输出结果比较麻烦，可能需要根据 MySQL EXPLAIN 输出的列手动映射。

方法四：数据库层面的分析工具

别忘了，MySQL 本身就提供了分析工具。

原理和作用：

直接利用 MySQL 提供的工具来监控和分析查询性能。

操作步骤：

慢查询日志 (Slow Query Log):
- 在 MySQL 配置文件 (my.cnf 或 my.ini) 中启用慢查询日志。
- 设置一个阈值 long_query_time (比如 1 秒)，超过这个时间的查询会被记录下来。
- 可以选择是否记录没有使用索引的查询 log_queries_not_using_indexes。
- 配置日志文件路径 slow_query_log_file。
- 例子 (my.cnf)：
```
[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 1
log_queries_not_using_indexes = ON
```
- 重启 MySQL 服务使配置生效。
- 运行你的应用，一段时间后检查慢查询日志文件。里面会包含执行缓慢的 SQL 语句。
- 拿到这些 SQL，去客户端执行 EXPLAIN。
Performance Schema:
- MySQL 5.6+ 提供了 Performance Schema，可以收集详细的性能数据，包括语句执行统计、等待事件等。配置和使用相对复杂，但功能强大。可以通过查询 performance_schema 库里的表来分析。
第三方工具 (如 pt-query-digest)：
- Percona Toolkit 里的 pt-query-digest 是一个非常强大的工具，可以分析慢查询日志、常规日志或 tcpdump 抓包的数据，生成详细的查询性能报告。
数据库 GUI 工具：
- 很多图形化工具（如 MySQL Workbench, DBeaver, Navicat）都集成了 EXPLAIN 功能。你可以在这些工具里打开一个 SQL 编辑器，粘贴从应用日志或 P6Spy 获取的 SQL，然后点击它们提供的“执行计划”或“Explain”按钮，通常会以更友好的图形化界面展示结果。

怎么用 EXPLAIN？

这些方法的核心是先捕获到有问题的 SQL 语句，然后使用标准的 EXPLAIN 命令或者工具自带的分析功能来查看执行计划。

优点：

不侵入应用代码。
可以捕获生产环境实际运行的慢查询。
pt-query-digest 等工具能做聚合分析，找出最需要优化的查询类型。

EXPLAIN 结果怎么看？（简版）

拿到 EXPLAIN 的结果后，重点关注以下几列：

id : 查询中每个 SELECT 的序号。
select_type : SELECT 的类型（SIMPLE, PRIMARY, SUBQUERY, UNION 等）。
table : 涉及的表名。
type : 非常关键！ 连接类型，表示 MySQL 查找行的方式。性能从好到差大致为：system > const > eq_ref > ref > range > index > ALL。看到 ALL（全表扫描）或 index（全索引扫描，但没用 WHERE 有效过滤）通常意味着有问题。理想情况是 ref、eq_ref 或 range。
possible_keys : 可能使用的索引。
key : 非常关键！ 实际使用的索引。如果是 NULL，表示没用索引。
key_len : 使用的索引的长度。越短越好（通常意味着索引选择性更好）。
rows : MySQL 估计要扫描的行数。越少越好。
Extra : 非常关键！ 包含额外信息。
- Using index: 好事！表示查询使用了覆盖索引，数据直接从索引中获取，不用回表。
- Using where: 表示在存储引擎层找到行后，MySQL 服务器层还需要进一步用 WHERE 条件过滤。
- Using temporary: 不好！表示 MySQL 需要创建临时表来处理查询，常见于 GROUP BY 或 ORDER BY 操作，性能开销大。
- Using filesort: 不好！表示 MySQL 需要在内存或磁盘上进行额外的排序操作，常见于 ORDER BY 的列没有合适的索引，性能开销大。

优化建议

根据 EXPLAIN 的结果：

如果 key 是 NULL，或者 type 是 ALL，检查 WHERE 子句涉及的列，为它们创建合适的索引。
如果 type 是 index，但 rows 很大，说明在扫描整个索引，检查 WHERE 条件能否利用索引过滤更多数据。
如果 Extra 出现 Using temporary 或 Using filesort，检查 GROUP BY 和 ORDER BY 的列是否有索引，或者能否优化查询逻辑避免这些操作。
注意联合索引的顺序，确保查询条件能匹配索引的最左前缀。
如果索引已经存在但没被使用 (possible_keys 里有，但 key 是 NULL)，可能是因为 MySQL 认为全表扫描更快（比如表很小，或者查询需要扫描大部分数据），或者索引选择性不高。可以尝试用 FORCE INDEX (不推荐，应优先优化查询或索引) 或分析原因。
对于亿级数据，考虑数据库分区 (Partitioning)。