数据库连接池与MyBatis核心原理：从配置调优到企业级避坑指南

数据库连接池这个东西，我在企业里见过太多“出事了才想起来”的组件。很多团队用着 Spring Boot 的默认配置，项目上线半年没有任何问题，结果某个大促或批量任务一跑，数据库连接疯涨，接口集体超时，最后看监控才发现连接池参数压根没调过。而 MyBatis 作为国内最主流的 ORM 框架，连接池和它的交互链路又是另一个盲区：明明 SQL 没问题，为什么事务一加 read-only 就报错？为什么一个方法里查两次数据却走到了同一个连接？这篇文章不聊那种“五分钟跑通 Demo”的东西，我以 MyBatis 第九篇的身份，把连接池从原理、参数、监控到企业规范里的常见坑一次说透，适合正在用 Spring Boot + MyBatis 做企业项目的开发同学，也适合准备面试时想摆脱八股文的读者。

1. 数据库连接不是“用完关掉”这么简单：一张连接的生命周期账

1.1 没有池化时，一次 SQL 背后有多少隐形成本

先看回最原始的 JDBC 写法，很多初学者都见过：

java复制Class.forName("com.mysql.cj.jdbc.Driver");
try (Connection conn = DriverManager.getConnection(url, username, password);
     PreparedStatement ps = conn.prepareStatement("SELECT * FROM user WHERE id = ?")) {
    ps.setLong(1, 1L);
    try (ResultSet rs = ps.executeQuery()) {
        // ...
    }
}

这段代码能跑，但千万别以为它只是“每次多 new 一个连接”而已。一次 DriverManager.getConnection() 背后，MySQL 服务端要完成的动作包括 TCP 三次握手、客户端认证、权限校验、获取当前线程的连接会话、初始化会话变量。在公网环境或数据库和应用的网络抖动时，这个过程可能达到几十甚至上百毫秒。换句话说，一条 SQL 本身只花 5 毫秒，连接却花了 30 毫秒，那你系统的吞吐量直接掉了 80% 以上。

更狠的是连接泄漏。用 try-with-resources 还好，老代码里如果 connection.close() 没写在 finally 里，应用容器一重启，数据库那边会躺着几千个休眠连接。我之前接手过一个老系统，MySQL max_connections 配的是 2000，日常请求不到 1000，但每天早上 10 点准时报警 Too many connections。查下来就是某个定时任务里的 Statement 没关，Statement 不关，底层连接也不会返回给池。

1.2 池化解决的不只是“慢”，还有“崩”

连接池做的事很朴素：在内存里维护一批已经建立好的连接，应用要连接时直接借，用完还回来，而不是销毁重建。

你可以把它理解成食堂打饭窗口。如果没有连接池，相当于每次打饭都从洗米、煮饭开始；有了连接池，饭是提前煮好的，你只管拿餐盘打菜就行。节省的时间是次要的，关键是系统不会因为瞬时并发把数据库打崩。

池化模型通常包含几个核心概念：

• 空闲连接：已经建立但当前没有被业务占用的连接。
• 活跃连接：正在被业务线程持有、执行 SQL 的连接。
• 最小空闲数：池里始终保底保留的连接数，避免高并发来时现建连接。
• 最大连接数：池允许同时存在的连接上限，超过就得排队等待。
• 等待超时：业务线程要连接，但池里没有空闲连接，最多等多久。

数据库服务端还有一个要命的问题：wait_timeout 默认 8 小时。如果你业务系统凌晨没有流量，池里的空闲连接会被 MySQL 主动断开，但连接池自己不知道。第二天早高峰第一个请求拿到这个“僵尸连接”，执行 SQL 就可能直接抛 CommunicationsException。这也是为什么企业级配置里几乎必有 connection-test-query 或者心跳检测机制。

提示：不要以为连接池是“锦上添花”的性能组件，它在高并发场景下的价值是保护数据库不被打垮，这才是第一优先级。

1.3 MyBatis 拿到连接的时机比你想象的晚

很多人误以为 MyBatis 每次执行 SQL 都会重新创建连接，其实不是。MyBatis 的架构里有三层和连接相关：

• SqlSessionFactory 负责创建 SqlSession。
• SqlSession 是执行 SQL 的门面，内部持有 Executor。
• Executor 每次执行 SQL 时，才通过 Environment 里的 DataSource 去拿连接。

换句话说，SqlSession 打开不等于立刻占用连接。如果你在循环里执行多条 SQL，默认情况下每条 SQL 都可能从连接池取一次连接、还一次连接。Spring 整合 MyBatis 后，事务管理器会决定这些 SQL 到底共享一个连接还是各拿各的。这也是为什么 Spring 环境下要多用 @Transactional 包住一组 SQL，目的不是“装模作样地开事务”，而是让这些 SQL 绑定同一个连接，减少反复从池里借还的开销，同时保证事务一致。

2. Spring Boot 下的 HikariCP：一份能落地的连接池配置与调优逻辑

2.1 为什么 Spring Boot 2.x 默认选 HikariCP

Spring Boot 2.x 的默认数据源就是 HikariCP。它快的原因不是玄学，而是做了几件很实在的事：

• 字节码级别精简，HikariCP 的 jar 包很小，代码路径短，方法调用开销低。
• 自己实现了 FastList 替代 ArrayList，避免每次 getConnection 时做越界检查和集合复制。
• 无锁并发集合 ConcurrentBag，多个线程借连接时减少竞争。

但默认好不代表不用调。Hikari 的默认配置是“保守可运行”，绝不是“生产最优”。比如默认 maximumPoolSize 是 10，如果你的接口 QPS 是 2000，平均每个请求占用连接 50ms，那 10 个连接也就撑 200 QPS，超出的全在等连接。

2.2 一份我常用的 HikariCP 配置模板

在 Spring Boot 的 application.yml 里，配置长这样：

yaml复制spring:
  datasource:
    hikari:
      pool-name: OrderCenterHikariPool
      minimum-idle: 10
      maximum-pool-size: 30
      idle-timeout: 300000
      connection-timeout: 30000
      max-lifetime: 1800000
      connection-test-query: SELECT 1
      validation-timeout: 3000

逐一解释这些参数，别只抄不思考：

• pool-name：给连接池起名，线上监控里定位问题非常关键。
• minimum-idle / maximum-pool-size：空闲保底 10，最大 30。这个数字要看业务并发和数据库规格综合定，不是越大越好。
• idle-timeout：空闲连接超过 5 分钟且当前池中连接数大于 minimum-idle 时，才会被回收。小于 minimum-idle 的空闲连接不会被回收。
• connection-timeout：调用方等待连接的最长时间，30 秒是比较保守的。很多业务场景建议 5 秒以内，否则大量线程会堆积在“等连接”上。
• max-lifetime：连接最大存活时间 30 分钟，必须小于数据库的 wait_timeout。如果 MySQL 的 wait_timeout 是 8 小时，30 分钟的设置能确保连接不会因为服务端断开而失效。
• connection-test-query：连接拿出来前做一次探活。MySQL 驱动 8.0 以上其实可以不配，JDBC 4 规范支持 ping 方式探活，但保留 SELECT 1 能兼容更多中间件和代理场景。

注意：idle-timeout 和 max-lifetime 不是一回事。前者管空闲连接回收，后者管连接总生命周期。一个连接即使一直被使用，到 max-lifetime 时也会被强制“退休”，这是为了规避数据库或网络设备层的连接老化问题。

2.3 maximumPoolSize 到底给多少，数据依据是什么

业界常听到一个说法：maximumPoolSize = ((core_count * 2) + effective_spindle_count)。这个公式来自 HikariCP 作者 Bret Woolley 的分享，核心逻辑是：数据库连接是串行处理 SQL 的，一个连接同一时刻只能执行一个 Statement，连接数超过某个阈值后，加连接并不能线性提升吞吐，反而会增加上下文切换和数据库端线程开销。

实际落地时我会按这套思路估算：

1. 看核心接口的 TP99 耗时，假设单次 SQL 执行平均耗时 10ms。
2. 看核心接口 QPS，假设 1000。
3. 单连接每秒能处理的请求数约 1000 / 10 = 100。
4. 理论最小连接数 1000 / 100 = 10，考虑波动和慢 SQL，最终乘 1.5~2 倍。

所以一个 QPS 1000 的服务，连接池配 20 到 30 是合理的。如果某个 SQL 平均就要 200ms，那 30 个连接也只能撑 150 QPS，此时该优化的不是连接池，而是这条 SQL 本身。

不要天真地以为“数据连接池最大连接数越大越好”。把 maximum-pool-size 配成 500，真有 500 个并发请求进来，数据库端会同时创建 500 个线程处理，CPU 光切换上下文就忙不过来，慢 SQL 会更慢。

3. 真正遇到 “Write operations are not allowed in read-only mode” 时，我在想什么

3.1 这个报错的经典现场

这个报错在 MyBatis 相关搜索里很常见，完整文案一般是：

code复制org.springframework.dao.InvalidDataAccessApiUsageException: 
Write operations are not allowed in read-only mode (FlushMode.MANUAL): 
Cannot execute INSERT/UPDATE/DELETE statement...

第一次碰到时，我的第一反应是查哪条 SQL 写了删除或者更新，结果 SQL 没问题，单独执行也正常。后来才意识到问题出在事务上。Spring 的 @Transactional(readOnly = true) 并不只是“告诉数据库这是一个只读事务”，对 MyBatis 来说，它还会把当前 SqlSession 的 FlushMode 设置为 MANUAL。

复现场景特别简单：

java复制@Service
public class UserService {

    @Transactional(readOnly = true)
    public void updateUserName(Long id, String name) {
        userMapper.updateName(id, name);
    }
}

只要方法标记了 readOnly = true，又在里面调用了 insert/update/delete 操作，MyBatis-Spring 在事务同步管理器里拿到的就是一个“只读连接”，底层调用时会触发拦截，直接把写操作挡下来。

排查思路总结成三句话：

• 先看方法上有没有 @Transactional(readOnly = true)。
• 再看有没有 AOP 切面给 Service 统一加了只读事务。
• 最后看这类 Service 是否被同类内部方法自调用，导致事务注解没生效，注意这时报错可能表现为另一副面孔。

3.2 FlushMode.MANUAL 带来的隐藏风险

FlushMode 是 MyBatis 内部控制一级缓存刷写时机的开关。默认情况下 FlushMode 是 AUTO，在查询前或事务提交前，Executor 会把一级缓存里的脏数据刷新到数据库。当 Spring 标记 readOnly = true 时，MyBatis-Spring 会把 SqlSession 的 FlushMode 改为 MANUAL，意思是“我自己管刷新，不自动 flush”。

这个设计本来是为了省掉只读场景下的无谓刷写，但它有一个连带效应：如果有人在只读事务里偷偷做了写操作（比如通过原生 JDBC 或者走了另一个 SqlSession），写操作可能没有立即落地，而同事务后续的查询又可能读到一级缓存里的旧值。这种问题比直接报错更难排查，因为它不报错，只是数据“看起来不对”。

所以企业规范里会有一条硬性要求：查询方法才允许加 readOnly = true，写操作和查询不要混在同一个事务方法里。这不是性能洁癖，是 MyBatis 的 FlushMode 机制决定了混用容易踩坑。

3.3 事务和连接池的绑定关系，也是排查这一类问题的主线

顺着这个报错往下想，你会发现它本质上暴露的是 Spring 事务如何从连接池拿连接、如何标记连接的链路。

Spring 的事务管理器 DataSourceTransactionManager 在开启事务时会做几件事：

1. 从 DataSource 里借出一个连接。
2. 把连接的 autoCommit 关闭。
3. 把当前连接绑定到线程本地变量 TransactionSynchronizationManager 里。

后面的 DAO 操作只要走同一个 DataSource，就不会再去连接池借新连接，而是复用当前线程绑定的连接。MyBatis 的执行器拿到的就是这个被标记了只读的连接。

这就解释了为什么多数据源场景下事务特别容易懵圈：如果你的 PlatformTransactionManager 绑定的是主数据源，但某项操作却走了从数据源，从数据源会从自己的连接池重新拿连接，不参与主事务的管理，出现“事务没生效”的假象。

4. 企业里写 Mapper 的规范：从 if 标签到逻辑删除，全是从报错堆里长出来的

4.1 if 标签的六条经验

MyBatis 动态 SQL 的 if 标签是所有初学者最先接触、也最容易写错的地方。常见错误我整理成下面这些：

1. OGNL 表达式里字符串比较的坑

xml复制<if test="type == '1'">
    AND status = #{type}
</if>

使用 MyBatis 3.5.x 基本没问题，但有些老版本会把 '1' 当成字符而不是字符串，比较结果不符合预期。更稳妥的写法是用双引号包比较值：

xml复制<if test='type == "1"'>

或者直接用 type.equals("1")。说到底，test 内部是 OGNL 表达式，不是 XML 属性里的普通字符串，单双引号存在解析层级的问题，别想当然。

2. 遇到 < 号要转义

xml复制<if test="age < 18">
    AND age &lt; 18
</if>

<if> 的 test 属性和 SQL 片段里的小于号都可能被 XML 解析器误判为标签开头，所以 age < 18 要么写成 <，要么改成 age lt 18。OGNL 支持 lt、gt、lte、gte 这类运算符，能少很多转义麻烦。

3. 判断空字符串不等于“判断非空”

很多团队会写：

xml复制<if test="name != null and name != ''">

判断空字符串同理：

xml复制<if test="name == null or name == ''">

4. 参数是 Integer 类型时，判断 != '' 常常是多余的。 OGNL 对 Integer 和空字符串的比较在某些场景会产生意外结果，更规范的是直接只判断 null。

5. #{} 和 ${} 不要混。 if 标签里只能写参数判断，SQL 片段里拼接排序字段、表名时才用 ${}，但必须严格控制传入值，否则就是注入风险。

6. 一个 SQL 片段别塞太多 if。 动态 SQL 一旦超过 10 个条件，读起来极其痛苦，测试覆盖也跟不上。企业里的规范一般是：WHERE 后面最多 5 到 6 个左右条件，再多就应该拆查询方法，或者配合 MyBatis-Plus 的 Wrapper 来做。

4.2 逻辑删除与“临时想看看已删除数据”怎么处理

逻辑删除是企业的标配，物理删除在多数核心业务里都被禁止。MyBatis-Plus 的逻辑删除配置很简单：

yaml复制mybatis-plus:
  global-config:
    db-config:
      logic-delete-field: deleted
      logic-delete-value: 1
      logic-not-delete-value: 0

配置好之后，MP 会在生成的 SQL 后面自动追加 deleted=0，同时对 deleteById 这类方法自动转成 UPDATE ... SET deleted=1。这个机制大多数时候很省心，但隐患在于：你没法用一条普通 SQL 查出来“已被逻辑删除”的数据。

有一种常见需求是管理端要恢复已删除数据，或者对账系统要把已删除的数据捞出来核对。MP 提供了一个注解：

java复制@InterceptorIgnore(tenantLine = "1")
@Select("SELECT * FROM user WHERE id = #{id}")
User selectEvenDeleted(Long id);

如果没做这种定制，你别自己偷偷写一条不带 deleted=0 的 SQL 就想绕过拦截，因为 MP 对普通 Mapper 方法的拦截是基于方法解析的，自定义 SQL 里如果手动写了删除标记字段，极可能出现重复拼接，SQL 变成 WHERE deleted = 0 AND deleted = 0，虽然不报错，但说明你根本没搞清楚框架在帮你做什么。

经验：逻辑删除配置是全局的，但每个业务表都必须有 deleted 字段，且索引设计要把 deleted 字段纳入考虑。删除标记字段加入联合索引后，查询才能走好索引。

4.3 关于两个 OR 条件的“括号政治”

“mybatis flex 两个 or”这个热搜词对应的真实问题，我在几个群里都见过：两个 OR 条件没加括号，结果查询结果完全不对。

看这段伪 SQL：

sql复制WHERE status = 1 OR status = 2 AND type = 3

SQL 的运算符优先级里 AND 高于 OR，所以这个条件真正等价的表达是：

sql复制WHERE status = 1 OR (status = 2 AND type = 3)

如果你的意图是“状态是 1 或 2，且类型是 3”，就必须写成：

sql复制WHERE (status = 1 OR status = 2) AND type = 3

在 MyBatis 动态 SQL 里拼这种条件时，括号的位置就是最容易翻车的地方：

xml复制<where>
    <if test="type != null">
        type = #{type}
    </if>
    <if test="statusList != null and statusList.size() > 0">
        AND (
        <foreach collection="statusList" item="s" separator="OR">
            status = #{s}
        </foreach>
        )
    </if>
</where>

foreach 里 separator 用的是 OR，如果外层漏了括号，就会把前面的条件一起“或”进去。写这种代码最稳的方法是先在一张纸上把条件组画出来，括号层级有几种，SQL 就分几层。条件组超过两层时，建议用 MyBatis-Plus 的 and(wrapper -> wrapper.eq(...).or().eq(...)) 这种嵌套写法，比手工拼 XML 可读性好太多。

4.4 多数据源下的批量操作：别让 saveOrUpdateBatch 背锅

多数据源在国内企业里太常见了，订单库、用户库、日志库分开，Spring Boot 通过 AbstractRoutingDataSource 做动态数据源。这种架构下一旦出现“saveOrUpdateBatch 多数据源的问题”，十有八九不是框架 bug，而是事务边界没划清楚。

批量操作本身要在一个事务里完成，单数据源下简单，@Transactional 就行。但多数据源下，Spring 默认的事务管理器只能绑定一个数据源，批量操作跨库时就变成了“A 库成功、B 库失败”，而且没有整体回滚。

我见过最典型的翻车场景是：一个导出功能边读主库边写日志库，批量保存日志用 saveOrUpdateBatch，本地测试数据量小看不出问题，一上生产几万条数据同时写，日志库连接池被打满，批量保存超时。这时主库的读操作已经完成了，日志库那边报错，接口异常，但调用方已经收到一半数据，状态非常尴尬。

规范的规避方案有几个：

• 如果强一致，引入 Seata 或本地消息表做最终一致。
• 如果允许弱一致，把日志库的写操作异步化，丢到 MQ 里处理。
• 批量操作拆分批次，比如每 500 条一批提交，避免单批时间过长占用连接池连接。

还有个小细节：saveOrUpdateBatch 底层本质上是先查一遍再决定 insert 还是 update，批量执行时会产生大量查询 SQL，比如 1 万条数据，它可能先执行 1 万次查询。如果你确定这批数据不会存在“既有又无”的混合状态，直接拆成批量 insert 和批量 update 更高效。

5. MyBatis 原理级理解：连接池、缓存、代理是面试的高频三件套

5.1 Mapper 接口是如何“凭空”变成 SQL 执行的

热词里有一条“mybatis 原理”和“mybatis 源码”，面试里几乎是必问。很多初学者以为 MyBatis 通过反射给 Mapper 接口生成了实现类，其实用的是 JDK 动态代理。

启动阶段，MyBatis 扫描 @Mapper 接口，为每个接口创建一个 MapperProxyFactory。运行时调用 userMapper.selectById(1)，实际进入 MapperProxy 的 invoke 方法。它做的事情有三件：

1. 根据方法名和参数类型，从 Configuration 里找到对应的 MappedStatement。
2. 创建一个 SqlSession 模板对象（Spring 环境下是 SqlSessionTemplate）。
3. 调用 SqlSession 的 select/insert/update/delete 方法执行 SQL。

SqlSession 再往下走就是 Executor，Executor 执行前会先处理一级缓存，然后通过 StatementHandler 创建 JDBC 的 PreparedStatement，从连接池里拿连接，最后执行并映射结果。

面试时能把这个链路讲出来，比背十篇八股文有用得多。因为你在表达“我是真的通过源码或 Debug 一步步看过的”。

5.2 MyBatis 缓存：一级缓存和连接占用是互相影响的

一级缓存默认开启，作用范围是同一个 SqlSession。Spring 整合后，默认每个方法都新建 SqlSession，一级缓存意义有限；只有加了事务，多个 Mapper 方法在同一个 SqlSession 里执行，一级缓存才会被共享。

注意这个点和连接池的关联：一级缓存的生命周期 = SqlSession 生命周期 = 事务生命周期 = 连接占用周期。如果某个事务方法里有慢查询，连接池里这条连接会被占用很久。如果你再混入“查完一次不提交、继续做远程调用”的写法，连接占用时间会进一步放大。线上连接池被打满时，第一件事应该是看有没有长事务。

二级缓存默认不开启，而且企业项目里我基本不建议用。原因很简单：多表联查的结果缓存失效策略很难写，一旦数据更新没刷缓存，线上就会出“数据一直不变”的诡异问题。真要缓存，请放到 Redis 层并由业务代码显式控制。

5.3 配置打印 SQL 这个问题，实际是为了看清连接和事务

热词“mybatis 配置打印”其实是很实在的生产排查手段。在 Spring Boot 里配置：

yaml复制logging:
  level:
    com.example.project.mapper: debug

把 Mapper 包路径的日志级别调到 debug，MyBatis 就会打印执行的 SQL、参数和返回行数。但只开这个还不够，想排查连接池相关的问题，还要在数据源配置里加：

yaml复制spring:
  datasource:
    hikari:
      leak-detection-threshold: 60000

这个参数很关键。它表示连接从池里借出后，如果超过 60 秒还没归还，HikariCP 会在日志里输出一条连接泄漏告警，并附上当时获取连接的调用栈。企业环境里我建议这个阈值设在 10 到 30 秒之间，太小会误报（比如慢查询本来就超过 30 秒），太大就失去了发现的及时性。

另外配合一个自定义拦截器可以打印完整 SQL 耗时，MyBatis 的 Interceptor 接口可以做这件事情，但对于绝大多数团队，先把 mapper 日志打开就够用了。

6. 企业开发规范落到团队里，我最后会要求这几条

把以上内容收敛到团队开发规范里，我会要求项目在立项初期就定下这几条，而不是等出了问题再去补：

1. 数据库连接配置必须代码评审。连接池的 maximum-pool-size、connection-timeout、max-lifetime 不能谁想改就改，改动必须有压测数据支撑。
2. 事务注解必须有明确语义。查询方法默认不加 readOnly，加了就必须保证内部没有任何写操作；写操作事务方法里不要做远程调用、不要做 Thread.sleep。
3. Mapper 方法的返回值不能是 null 就返回 List，MyBatis 对查询不到数据的方法会自动返回空集合，这个行为很多人不知道，却总在业务层写一堆空指针判断来兜底。
4. 禁止在 XML 里写“一眼看不懂”的动态 SQL。一个查询方法超过 15 行 XML，就该考虑拆条件对象（Query DTO）或者在 Service 层用 Wrapper 拼接。
5. 连接池监控指标要上到告警系统。至少盯三个指标：活跃连接数、等待获取连接次数、连接池获取连接耗时。一旦“等连接耗时”超过 200ms，基本说明池子不够或存在连接泄漏。
6. 逻辑删除字段的命名所有表统一。不要订单表叫 is_deleted、用户表叫 deleted_flag、日志表叫 del，统一成 deleted，MP 配置才能一套走天下。

我经历过不止一次线上故障，最后定位到根因都不是什么高深算法，而是连接池参数不合理、事务边界划错、动态 SQL 括号放错位置这类基础问题。尤其要提一下连接泄漏的排查：当你发现连接池活跃连接数持续走高且不回落的瞬间，先用 SHOW PROCESSLIST 看数据库端哪些连接卡了很长时间，再到应用日志里搜 leak-detection-threshold 的告警，基本能锁定是哪台机器、哪个方法、哪条 SQL 没归还连接。

踩过几次坑之后，我现在接手一个新项目，第一件事不是看业务代码写得多花哨，而是先把配置类和 Mapper.xml 全部翻一遍。数据库连接池和 MyBatis 的行为边界一旦搞明白，很多“诡异问题”其实都是可预期的结果。这套东西不复杂，但特别值得在项目里花一两天整理成规范。