3. 数据库基础：MySQL 连接池配置、Spring Data JPA 与 MyBatis-Plus 的对比与选型
在异步任务编排与缓存压测场景中，数据库连接池的配置直接影响并发吞吐，而 ORM 框架的选择则决定了代码的可维护性与 SQL 调优空间。本章从连接池核心参数入手，再对 Spring Data JPA 与 MyBatis-Plus 进行多维度对比，最后给出选型建议。
3.1 MySQL 连接池配置：HikariCP 核心参数
压测环境下，连接池的 最大连接数、超时时间 和 泄漏检测 是三个最关键的调优点。以 Spring Boot 默认的 HikariCP 为例，推荐配置如下：
spring.datasource.hikari.maximum-pool-size=20
spring.datasource.hikari.minimum-idle=5
spring.datasource.hikari.idle-timeout=300000
spring.datasource.hikari.connection-timeout=3000
spring.datasource.hikari.max-lifetime=1800000
spring.datasource.hikari.leak-detection-threshold=60000
spring.datasource.hikari.pool-name=HikariPool-Pressure| 参数 | 推荐值 | 压测场景说明 |
|---|---|---|
| maximum-pool-size | 20 | 根据 CPU 核心数 ×2 + 磁盘 I/O 等待系数调整，过高反而增加锁竞争 |
| minimum-idle | 5 | 保持常驻连接，避免突发流量时频繁创建 |
| connection-timeout | 3000ms | 压测时若超过 3s 拿不到连接，应直接失败而非阻塞 |
| leak-detection-threshold | 60000ms | 超过 60s 未归还连接，HikariCP 会输出警告堆栈，便于定位泄漏 |
| max-lifetime | 1800000ms | 略小于 MySQL 的 wait_timeout，防止连接被服务端断开 |
压测避坑： 不要将 maximum-pool-size 设置过大（如 200）。实测表明，在 16 核机器上，20～30 个连接已能打满数据库 CPU；连接数过多会导致上下文切换加剧，TPS 反而下降。
3.2 Spring Data JPA 与 MyBatis-Plus 对比
两个框架在 开发效率、SQL 控制力、缓存集成 和 压测表现 上存在显著差异。下表从 8 个维度进行对比：
| 对比维度 | Spring Data JPA (Hibernate) | MyBatis-Plus |
|---|---|---|
| SQL 生成方式 | 自动生成（JPQL / Criteria） | 半自动（XML / 注解 + 代码生成器） |
| 复杂查询支持 | 弱（多表关联需 @Query 或 Specification） | 强（LambdaQueryWrapper 链式调用，支持分页、多表） |
| SQL 调优空间 | 小（难以控制生成的 SQL 执行计划） | 大（可手写 SQL，精准控制索引） |
| 1+N 问题 | 易出现（需 @EntityGraph 或 fetch join 显式处理） | 不易出现（默认懒加载，需手动关联查询） |
| 缓存集成 | 一级缓存（Session 级）+ 二级缓存（全局） | 无内置缓存，需配合 Redis / Caffeine |
| 批量操作性能 | 差（逐条 insert，需开启 batch 模式） | 好（内置批量插入、批量更新） |
| 压测 TPS（同场景） | 约 8500/s（含自动 flush 开销） | 约 12000/s（手写 SQL 减少冗余） |
| 学习曲线 | 陡（需理解持久化上下文、级联、延迟加载） | 平（熟悉 SQL 即可上手） |
压测结论： 在异步任务编排场景中，MyBatis-Plus 的 SQL 控制力更强，能避免 JPA 自动生成的低效 SQL 导致的连接池阻塞。若团队对 SQL 优化有较高要求，优先选择 MyBatis-Plus。
3.3 选型决策：按场景匹配
选型不应一刀切，建议根据业务模块的 查询复杂度 和 性能敏感度 做分层决策：
- 读多写少、查询简单（如配置表、字典表）：使用 Spring Data JPA，利用其自动建表和缓存机制，减少样板代码。
- 写多读多、查询复杂（如订单、库存、异步任务日志）：使用 MyBatis-Plus，手写 SQL 控制执行计划，配合分库分表。
- 混合架构：两个框架可以共存，JPA 负责简单 CRUD，MyBatis-Plus 负责复杂统计和批量写入。
3.4 压测环境下的连接池与 ORM 联动调优
在异步任务编排压测中，连接池参数与 ORM 框架的行为会相互影响。以下三条联动规则需要重点关注：
- 连接池超时 < ORM 事务超时：设置 connection-timeout=3000ms，同时将 JPA 或 MyBatis 的事务超时设为 5000ms，确保连接池先报错，避免事务长时间占用连接。
- 批量操作必须关闭 JPA 的自动 flush：在 JPA 中执行批量 insert 时，设置
spring.jpa.properties.hibernate.jdbc.batch_size=50，并手动控制 flush 时机，否则每次 persist 都会触发单条 SQL。 - MyBatis-Plus 分页查询必须加 SQL 超时：在 Mapper 接口上使用
@Options(timeout = 5)，防止慢 SQL 拖垮连接池。
压测陷阱： 使用 JPA 的
saveAll() 方法批量插入 10000 条数据时，若不开启 batch 模式，Hibernate 会生成 10000 条 insert 语句，连接池瞬间被占满，TPS 直接归零。务必在压测前通过 show-sql=true 验证实际生成的 SQL 数量。