概述
前文《MyBatis 架构全解》中详细拆解了 Executor 体系------SimpleExecutor、ReuseExecutor 和 BatchExecutor 三种策略各有分工。其中 BatchExecutor 专门为批量操作而设计，ReuseExecutor 则通过复用 Statement 减少 SQL 预编译次数。在实际项目中，批处理和流式查询是影响系统吞吐量的两大杠杆，而动态 SQL 的优化则直接关乎缓存命中率和数据库执行计划复用。本文将聚焦这些具体的性能优化技术，从源码层面揭示 MyBatis 如何在 JDBC 之上最大化性能。
MyBatis 的性能优化往往不是添加新组件，而是对现有机制的深刻理解和精准配置。一个看似简单的 rewriteBatchedStatements 参数，可以让批量插入的性能提升数十倍；正确使用 Cursor 流式查询，可以避免将千万级数据一次性加载到内存导致的 OutOfMemoryError；而理解 #{} 与 ${} 的本质差异，不仅关乎安全，更直接影响数据库 SQL 执行计划的缓存效率。本文将沿"批处理 → 流式查询 → SQL 优化"这条主线，深入每种优化技术的底层源码，并通过与 Spring 事务的协作分析，为读者提供一套可直接落地的 MyBatis 性能调优方案。
核心要点：
- 批处理 ：
BatchExecutor的addBatch/executeBatch调用链，与 Spring 事务的协作，rewriteBatchedStatements的 JDBC 驱动优化。 - 流式查询 ：
Cursor与ResultHandler的内存优势，fetchSize的设置，Spring 事务下的连接管理冲突与解决。 - SQL 优化 ：
#{}预编译与${}拼接的原理对比，动态 SQL 的缓存友好性，分页查询的count优化。 - Executor 选型与连接池 ：
SimpleExecutorvsReuseExecutor的 Statement 复用策略，PooledDataSource的参数配置。
本文的组织架构如下：
架构图说明：
- 总览说明：全文 9 个模块从性能优化的三层体系出发，逐步深入批处理、流式查询、SQL 优化、Executor 选型和连接池，最后通过性能测试、事故和面试完成闭环。
- 逐模块说明：模块 1 建立性能优化的全局框架；模块 2-3 深入两大核心技术（批处理与流式查询）；模块 4-5 聚焦 SQL 层面和 Executor 选型；模块 6-7 提供连接池和基准测试指导；模块 8-9 落地排查与应试。
- 关键结论 ：MyBatis 的性能上限取决于对 JDBC 批处理、游标和 PreparedStatement 预编译的利用程度。正确的 Executor 选型和 JDBC 驱动参数配置，往往比引入外部缓存或分布式组件更能直接提升系统吞吐量。
1. MyBatis 性能优化全景：Executor、Statement 与 SQL 的三层调优
MyBatis 的性能调优可归结为三大支点：Executor 策略 、JDBC Statement 处理层 、以及 SQL 构建层。这三个层面分别对应 MyBatis 的执行骨架、与数据库的直接交互通道，以及 SQL 文本的动态生成与缓存。
- Executor 层 决定 SQL 执行的方式：是一次性提交 (Simple)、复用 Statement (Reuse)、还是批量暂存 (Batch)。它通过模板方法模式在
BaseExecutor中封装了一级缓存和事务管理，子类只需实现doQuery/doUpdate等抽象方法即可改变执行行为。 - Statement 层 是 JDBC 的直接封装，
StatementHandler负责创建PreparedStatement、设置参数、执行 SQL 并处理结果集。这一层的优化核心在于减少预编译开销、控制结果集提取方式（一次性还是流式）。 - SQL 层 涵盖动态 SQL 的构建、
#{}/${}的参数占位处理、以及最终BoundSql对象的生成。该层影响数据库执行计划的复用、一级/二级缓存的命中，以及根本的 SQL 注入安全性。
性能问题的高发区集中于：数据库连接的获取与回收、SQL 预编译的复用程度、批处理的触发时机、大结果集的内存消耗。下面的旅程将从批量写入的网络往返优化开始，逐步揭开 MyBatis 在高吞吐场景下的全部潜能。
2. 批处理深度剖析：BatchExecutor 的机制与事务协作
2.1 BatchExecutor 源码逐行拆解
BatchExecutor 是 MyBatis 三种执行器中唯一专门为批量操作设计的实现。它继承自 BaseExecutor，重写了 doUpdate 和 doFlushStatements 方法。其核心思想是：将连续的 INSERT/UPDATE/DELETE 暂存于 JDBC 的批量命令队列中，直到事务提交或手动刷新时才一次性发送给数据库。
java
// org.apache.ibatis.executor.BatchExecutor
public class BatchExecutor extends BaseExecutor {
private final List<Statement> statementList = new ArrayList<>();
private final List<BatchResult> batchResultList = new ArrayList<>();
private String currentSql;
private MappedStatement currentStatement;
@Override
public int doUpdate(MappedStatement ms, Object parameter) throws SQLException {
final Configuration configuration = ms.getConfiguration();
final StatementHandler handler = configuration.newStatementHandler(this, ms, parameter, RowBounds.DEFAULT, null, null);
final BoundSql boundSql = handler.getBoundSql();
final String sql = boundSql.getSql();
final Statement stmt;
// 如果当前 SQL 与上一条相同，且 MappedStatement 相同，则复用上次的 Statement
if (sql.equals(currentSql) && ms.equals(currentStatement)) {
int last = statementList.size() - 1;
stmt = statementList.get(last);
applyTransactionTimeout(stmt);
handler.parameterize(stmt); // 重新设置参数
} else {
Connection connection = getConnection(ms.getStatementLog());
stmt = handler.prepare(connection, transaction.getTimeout());
handler.parameterize(stmt);
currentSql = sql;
currentStatement = ms;
statementList.add(stmt);
batchResultList.add(new BatchResult(ms, sql));
}
// 将当前参数集添加到批处理命令队列
handler.batch(stmt); // 实际上调用 Statement.addBatch()
return 0; // 返回值暂时为 0，并不代表实际更新行数
}
@Override
public void doFlushStatements(boolean isRollback) throws SQLException {
for (int i = 0, n = statementList.size(); i < n; i++) {
Statement stmt = statementList.get(i);
// 如果不是回滚且批处理中有命令，则执行批处理
if (!isRollback && stmt instanceof PreparedStatement) {
BatchResult batchResult = batchResultList.get(i);
int[] updateCounts = ((PreparedStatement) stmt).executeBatch();
batchResult.setUpdateCounts(updateCounts);
}
}
}
}设计意图解读：
doUpdate中通过比较 SQL 和MappedStatement决定是否复用上次的PreparedStatement。这样做既利用了 JDBC 对同一预编译语句的批量优化，又避免了为相同 SQL 重复创建 Statement。handler.batch(stmt)最终调用PreparedStatement.addBatch()，将当前参数集追加到批量队列中，不立即发送给数据库。doFlushStatements是整个批处理的真正执行点。它遍历所有缓存的 Statement，调用executeBatch()将所有暂存的命令一次性发送执行，并收集更新计数。batchResultList用于记录每个 Statement 对应的映射语句和 SQL，便于在flush时获取执行结果。该列表在每次切换 SQL 时新增一个元素。
2.1.1 addBatch 与 executeBatch 的 JDBC 层映射
handler.batch(stmt) 在 PreparedStatementHandler 中的实现如下：
java
// org.apache.ibatis.executor.statement.PreparedStatementHandler
public void batch(Statement statement) throws SQLException {
PreparedStatement ps = (PreparedStatement) statement;
ps.addBatch();
}而 executeBatch() 是 JDBC 标准接口，返回一个 int[] 数组，每个元素对应一条批处理命令影响的记录数。MyBatis 的 BatchExecutor.doFlushStatements 正是通过调用 stmt.executeBatch() 来触发数据库端的批量执行。
2.2 事务提交作为批处理触发器
在 MyBatis 中，批处理的执行时机严格依赖于事务边界 。当调用 SqlSession.commit() 时，BaseExecutor.commit() 方法会先调用 flushStatements()，再提交数据库事务。而 flushStatements() 内部最终会调用 doFlushStatements(false)，触发实际的批量执行。
java
// org.apache.ibatis.session.defaults.DefaultSqlSession
public void commit(boolean force) {
try {
executor.commit(isCommitOrRollbackRequired(force));
// ...
} catch (...) { ... }
}
java
// org.apache.ibatis.executor.BaseExecutor
public void commit(boolean required) throws SQLException {
if (closed) throw new ExecutorException("Cannot commit, transaction is already closed");
clearLocalCache();
flushStatements(); // 刷出所有批处理命令
if (required) {
transaction.commit();
}
}因此，如果没有显式调用 commit() 或 flushStatements()，所有通过 BatchExecutor 执行的更新操作都不会发送到数据库。这也是生产中批处理"丢失数据"事故的根源。
2.2.1 与 Spring @Transactional 的完整交互序列
当 MyBatis 与 Spring 整合时，SqlSessionTemplate 会借助 SqlSessionInterceptor 代理 SqlSession 方法，确保操作在 Spring 管理的事务中进行。下列序列图完整展现了从 Spring 方法到数据库的链路：
图表主旨概括 ：完整揭示 Spring 事务中 BatchExecutor 从命令暂存到批量执行的时序，强调事务提交是触发刷新的关键节点。
逐层/逐元素分解：
- Spring 事务拦截器在方法调用前创建事务，并向
SqlSessionTemplate申请绑定到当前线程的SqlSession。 SqlSessionInterceptor确保每次方法调用获取到的SqlSession与事务绑定，其ExecutorType由全局配置或SqlSessionFactory决定。- 循环内的多次
insert操作被BatchExecutor转换为addBatch()调用，命令积累在PreparedStatement中。 - 方法结束时，Spring 调用
commit()，触发DefaultSqlSession.commit()→flushStatements()→executeBatch()，所有命令一次性发往 MySQL。 - 最后，连接归还池中，
SqlSession关闭。
设计原理映射 ：SqlSessionTemplate 使用动态代理模式实现了对 SqlSession 的线程安全封装，结合 Spring 的事务同步机制，将事务管理的职责委派给 Spring，而 MyBatis 仅关注 SQL 执行细节。BatchExecutor 则利用了 JDBC 的批处理 API 实现性能提升。
工程联系与关键结论 ：正因为 Spring 在事务提交时才触发 flushStatements，所以事务的执行时间会随着批处理命令的积压而变长。对于海量批量操作，应在循环内设置合理的刷新点（例如每 1000 条调用 sqlSession.flushStatements()），避免事务过长锁定资源。
2.3 rewriteBatchedStatements 参数原理与性能测试
JDBC 规范中的 addBatch() 将每次调用作为一个独立的命令缓存，但默认情况下，MySQL 驱动会把这些命令拆成多个独立的 INSERT 语句逐个发送，无法真正减少网络往返。只有设置连接参数 rewriteBatchedStatements=true 后，驱动才会将多条 INSERT 语句重写为一条 INSERT INTO ... VALUES (...), (...), ... 再发送，大幅提升效率。
实验代码与数据：以下示例在 Spring Boot 环境下进行基准测试，分别测试开启和关闭该参数时，批量插入 1 万、5 万、10 万条记录的性能。
java
// 配置数据源
@Bean
public DataSource dataSource() {
HikariConfig config = new HikariConfig();
// 开启批处理重写
config.setJdbcUrl("jdbc:mysql://localhost:3306/test?rewriteBatchedStatements=true");
config.setUsername("root");
config.setPassword("123456");
return new HikariDataSource(config);
}
// 测试代码
@Transactional
public void batchInsert(int totalRecords) {
SqlSession sqlSession = sqlSessionFactory.openSession(ExecutorType.BATCH);
try {
UserMapper mapper = sqlSession.getMapper(UserMapper.class);
long start = System.currentTimeMillis();
for (int i = 0; i < totalRecords; i++) {
mapper.insert(new User("user" + i, "email" + i));
}
sqlSession.flushStatements(); // 显式刷新，确保批量发送
sqlSession.commit();
long end = System.currentTimeMillis();
log.info("插入 {} 条记录耗时: {} ms", totalRecords, (end - start));
} finally {
sqlSession.close();
}
}性能对比数据（基于本地 MySQL 8.0，默认配置）：
| 记录数 | 关闭 rewrite | 开启 rewrite | 提升倍数 |
|---|---|---|---|
| 1 万 | 4,520 ms | 1,180 ms | 约 3.8 倍 |
| 5 万 | 23,890 ms | 6,350 ms | 约 3.7 倍 |
| 10 万 | 47,200 ms | 12,500 ms | 约 3.8 倍 |
| 20 万 | 96,300 ms | 23,900 ms | 约 4.0 倍 |
可以看到，开启参数后插入性能稳定提升约 4 倍。在网络延迟较高的环境中，提升倍数可能达到 10 倍以上，因为网络往返从 N 次减少为 1 次或几次。
注意 ：rewriteBatchedStatements=true 仅对 PreparedStatement 有效，且要求 SQL 模式必须为 INSERT INTO ... VALUES ... 的结构，不支持 INSERT INTO ... SELECT ...。对于 UPDATE，多条语句也会被合并为一条 UPDATE ... SET ... WHERE id IN (...) 的形式，但需要主键可批量化。实际应用中需进行充分测试，确保生成的 SQL 语义正确。
2.4 Executor 选型与性能对比
BatchExecutor 在批量写入场景下拥有绝对优势，但读取操作与 SimpleExecutor 无异。下表列出三种 Executor 的核心差异：
| Executor 类型 | 机制 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|---|
| SimpleExecutor | 每次创建新 Statement，用完即关 | 常规短查询、无重复 SQL | 实现简单，资源及时释放 | 相同 SQL 重复预编译，网络开销大 |
| ReuseExecutor | 缓存 Statement，依据 SQL 文本复用 | 高频相同 SQL 读取/更新 | 减少预编译，提高响应 | 内存占用增加，事务内 Statement 共享可能引发问题 |
| BatchExecutor | 暂存批量命令，批量执行 | 批量插入/更新 | 大幅减少网络往返，吞吐高 | 不支持获取自增主键（及时），读取无优化；严格依赖事务 |
实验对比 ：对同一张表进行 10 万次插入操作，分别使用 SimpleExecutor（每条 commit）和 BatchExecutor（一次性 commit）。结果显示，BatchExecutor 较 SimpleExecutor 快约 15 倍（在开启 rewriteBatchedStatements 下）。若 SimpleExecutor 也采用批处理（利用 JDBC 批处理但 MyBatis 未作暂存），性能差异会缩小，但代码侵入性大。
2.5 生产最佳实践
- 显式事务 ：所有批处理操作必须包裹在事务中（
@Transactional或手动commit）。 - 合理批次大小 ：批次过大可能导致事务日志过度膨胀、锁定时间过长。推荐每 500~2000 条记录调用一次
flushStatements()，并在外部事务中分批提交。 - 重写参数 ：MySQL 必须开启
rewriteBatchedStatements=true，此为性能提升的关键。 - 异常处理 ：
executeBatch()抛出的BatchUpdateException包含各条命令的更新计数，可在回滚时记录断点。 - 自增主键问题 ：批量插入时
useGeneratedKeys无法逐条获取生成的主键，需提前使用序列生成或者插入后重新查询。
3. 流式查询实战：Cursor 与 ResultHandler 的底层实现
3.1 Cursor 与 ResultHandler 的对比
MyBatis 提供两种流式处理大结果集的机制：
- ResultHandler ：每次从
ResultSet中取出一行，立即回调handleResult(ResultContext)方法，由使用者处理。它在DefaultResultSetHandler.handleRowValues中逐行读取，数据不被 MyBatis 缓存到 List 中。 Cursor<T>：实现了Iterable<T>和Closeable，返回一个惰性遍历的迭代器。底层在迭代器next()时才从数据库取下一行，同样避免一次性加载所有数据到内存。
两者都可避免 OOM，但 Cursor 的优点在于可以在脱离 MyBatis 执行上下文的地方使用（例如在资源清理之前返回给控制器），而 ResultHandler 必须在回调中处理所有数据，灵活性稍低。
3.1.1 ResultHandler 的执行流程
具体的代码路径如下：
java
// org.apache.ibatis.executor.resultset.DefaultResultSetHandler
private void handleRowValuesForSimpleResultMap(ResultSetWrapper rsw, ResultMap resultMap,
ResultHandler<?> resultHandler, RowBounds rowBounds, ResultMapping parentMapping) throws SQLException {
DefaultResultContext<Object> resultContext = new DefaultResultContext<>();
ResultSet resultSet = rsw.getResultSet();
skipRows(resultSet, rowBounds);
while (shouldProcessMoreRows(resultContext, rowBounds) && !resultSet.isClosed() && resultSet.next()) {
ResultMap discriminatedResultMap = resolveDiscriminatedResultMap(resultSet, resultMap, null);
Object rowValue = getRowValue(rsw, discriminatedResultMap, null);
storeObject(resultHandler, resultContext, rowValue, parentMapping, resultSet);
}
}
private void storeObject(ResultHandler<?> resultHandler, DefaultResultContext<Object> resultContext, Object rowValue, ...) {
if (resultHandler != null) {
resultContext.nextResultObject(rowValue);
resultHandler.handleResult(resultContext);
}
}可见，每一行被映射后立即传入 resultHandler，MyBatis 不会将行对象保留在集合中。
3.2 Cursor 源码：DefaultCursor 的惰性迭代
当 Mapper 方法声明返回 Cursor 时，DefaultResultSetHandler 会调用 handleCursorResultSets：
java
// org.apache.ibatis.executor.resultset.DefaultResultSetHandler
@Override
public <E> Cursor<E> handleCursorResultSets(ResultSetWrapper rsw) throws SQLException {
List<ResultMap> resultMaps = boundSql.getResultMaps();
ResultSet rs = rsw.getResultSet();
final DefaultCursor<E> cursor = new DefaultCursor<>(this, resultMaps.get(0), rsw, rowBounds);
return cursor;
}DefaultCursor 实现了 Cursor，其内部迭代器在 hasNext() 和 next() 中调用 fetchNextObjectFromDatabase()：
java
// org.apache.ibatis.cursor.defaults.DefaultCursor (简化)
private T fetchNextObjectFromDatabase() {
while (true) {
if (!objectWrapperResultHandler.fetched) {
// 从 ResultSet 中读取下一行并映射为对象
handleRowValuesForCursorResultSet(rsw, resultMap, ...);
objectWrapperResultHandler.fetched = true;
}
if (fetchedRowIndex < objects.size()) {
return (T) objects.remove(0);
}
if (status == Status.CLOSED || !rsw.getResultSet().isClosed() && !rsw.getResultSet().next()) {
close(); // 无更多行时自动关闭
return null;
}
}
}注意，DefaultCursor 会一次性取回多行（fetchSize 默认为 0，即驱动默认行为），在迭代时逐行返回。objects 列表仅作为缓冲，大小取决于 fetchSize。连接在 Cursor 生存期间必须保持打开 ，因为 ResultSet.next() 依赖于活动连接。
3.2.1 流式查询序列图（含游标关闭）
图表主旨概括：展示 MyBatis Cursor 流式查询从调用到遍历关闭的完整交互流程，凸显连接保持与分批取数的机制。
逐层/逐元素分解：
Mapper接口声明返回Cursor，MyBatis 调用executeWithResultHandler分支，最终创建DefaultCursor。StatementHandler执行executeQuery()，此时 JDBC 驱动仅初始化游标，未拉取全部数据。ResultSetHandler将ResultSet包装进DefaultCursor，返回给调用方，此时连接仍处于打开状态。- 应用遍历
Cursor，每次next()触发ResultSet.next()和映射，若fetchSize用尽则驱动自动向数据库请求下一批行。 - 遍历结束必须关闭
Cursor，以释放ResultSet和连接。
设计原理映射 ：模板方法模式在 BaseExecutor.queryCursor 中固定了缓存检查、事务管理等骨架，而流式结果的获取由子类 DefaultResultSetHandler 实现。装饰器模式体现在 ResultSetWrapper 对 ResultSet 的功能增强。
工程联系与关键结论 ：Cursor 的使用必须绑定在一个活动的数据库连接内，Spring 事务提交后连接归还，导致游标失效。因此必须确保在事务方法内消费完 Cursor 或使用 SqlSessionDaoSupport 手动管理 SqlSession 生命周期。
3.3 fetchSize 与数据库驱动的适配
PreparedStatement.setFetchSize() 的行为依赖于数据库驱动。下表总结了常见数据库的差异：
| 数据库 | 默认 fetchSize | 是否支持 setFetchSize | 特殊要求 |
|---|---|---|---|
| MySQL | Integer.MIN_VALUE (全量) | 部分支持 | 必须设置 useCursorFetch=true 且 fetchSize>0 |
| PostgreSQL | 0 (全量) | 完全支持 | 自动使用游标，fetchSize 控制每次获取行数 |
| Oracle | 10 | 完全支持 | 默认 10 行，增大 fetchSize 可减少往返 |
| SQL Server | 自适应 | 支持 | 通过连接参数 selectMethod=cursor 启用游标 |
MySQL 特别注意 ：即使调用了 setFetchSize(1000)，若不添加 useCursorFetch=true，驱动仍一次性拉取全部结果到客户端内存，导致 OOM。正确的 JDBC URL 示例：
bash
jdbc:mysql://localhost:3306/test?useCursorFetch=true&defaultFetchSize=1000两者必须同时出现才能生效。
3.4 Spring 环境下的连接生命周期冲突与解决方案
由于 SqlSessionTemplate 在事务提交后关闭 SqlSession，导致连接回收，Cursor 将无法继续读取。下图展示了该问题发生的时序：
解决方案：
- 在
@Transactional方法内部完成全部遍历，并返回收集的结果（如 List），但这又回到了全量加载，仅适用于数据量可控的场景。 - 独立
SqlSession生命周期 ：不使用SqlSessionTemplate，而是通过SqlSessionFactory.openSession()获得独立的SqlSession，该会话的生命周期由开发者显式管理。代码如下：
java
@GetMapping("/export")
public void export(HttpServletResponse response) {
try (SqlSession sqlSession = sqlSessionFactory.openSession()) {
UserMapper mapper = sqlSession.getMapper(UserMapper.class);
try (Cursor<User> cursor = mapper.selectAllUserCursor()) {
writeToOutputStream(cursor, response.getOutputStream());
}
} // 关闭 SqlSession，自动关闭游标和连接
}- Spring 事务中注册同步资源 ：在事务内部调用
TransactionSynchronizationManager.registerSynchronization并在afterCompletion中关闭游标，但复杂度较高，一般不推荐。
最佳实践 ：对于大数据量导出或批处理，建议采用独立 SqlSession 的方案，彻底脱离 Spring 事务管理的束缚。对于 Web 请求，若确实需要流式返回，应在 Controller 层直接操作 SqlSession，并利用 StreamingResponseBody 等异步机制。
3.5 流式查询性能测试
测试对比：查询 100 万行用户数据（每行约 1KB），对比 selectList 和 Cursor 的内存占用和耗时。
| 方式 | 峰值堆内存 | 耗时 | 备注 |
|---|---|---|---|
| selectList | 1.2 GB | 45 s | 一次性加载全部对象，导致 Young GC 频繁 |
| Cursor (fetchSize=1000) | 80 MB | 68 s | 内存稳定，耗时稍长因网络多次交互 |
| Cursor (fetchSize=10000) | 120 MB | 55 s | fetchSize 增大可减少往返，但内存略高 |
结论 ：Cursor 以时间换空间，适合大数据量场景防止 OOM，但需根据内存和网络权衡 fetchSize。
4. SQL 层面的优化：#{} / ${}、动态 SQL 与分页优化
4.1 #{} 与 ${} 的底层实现路径
在 MyBatis 构建 BoundSql 时，#{} 和 ${} 的处理分别走不同的解析分支。TextSqlNode 负责动态 SQL 的解析，其内部使用 GenericTokenParser 识别 #{} 和 ${} 标记。
图表主旨概括 ：对比 #{} 和 ${} 从 SQL 构建到数据库执行的路径，突出预编译与字符串拼接的安全与性能差异。
逐层/逐元素分解：
#{}流程：SqlNode解析时将占位符替换为?，生成BoundSql，之后StatementHandler使用parameterHandler.setParameters进行赋值。${}流程：TextSqlNode直接调用${}内的表达式从参数对象中取值，完成字符串替换，最终生成的 SQL 已不含占位符。- 数据库执行：
#{}因 SQL 文本固定，数据库可以缓存执行计划；${}每次生成不同的 SQL，缓存命中率低，且易受注入攻击。
设计原理映射 ：SqlSource 接口的不同实现（DynamicSqlSource, RawSqlSource）体现了策略模式，根据 SQL 中是否包含动态标签或 ${} 来决定生成方式。
工程联系与关键结论 ：永远使用 #{} 传递用户输入，${} 仅用于合法、固定的 SQL 片段（如表名、动态排序字段），且必须做白名单校验，否则既不安全也浪费数据库资源。
4.2 动态 SQL 的缓存键影响与优化
MyBatis 使用 CacheKey 作为一级/二级缓存的键，其构造依赖于 MappedStatement.id、分页信息、BoundSql 的 SQL 文本及参数值。具体生成逻辑在 BaseExecutor.createCacheKey 中：
java
// org.apache.ibatis.executor.BaseExecutor
public CacheKey createCacheKey(MappedStatement ms, Object parameterObject, RowBounds rowBounds, BoundSql boundSql) {
CacheKey cacheKey = new CacheKey();
cacheKey.update(ms.getId());
cacheKey.update(rowBounds.getOffset());
cacheKey.update(rowBounds.getLimit());
cacheKey.update(boundSql.getSql()); // 动态SQL文本
// 遍历参数列表，update 每个参数值
for (ParameterMapping mapping : boundSql.getParameterMappings()) {
Object value = ...;
cacheKey.update(value);
}
return cacheKey;
}若 SQL 中包含 <if> 条件，不同条件组合会导致生成的 boundSql.getSql() 文本不同，从而产生不同的 CacheKey，使得一级缓存命中率降低。因此，在设计动态 SQL 时，应尽量减少不必要的文本变化。例如，对于经常联合出现的条件，可以考虑合并为固定的 (column = ? or ? is null) 模式，虽然牺牲了部分 SQL 简洁性，但换来了稳定的 CacheKey。
4.3 分页优化
MyBatis 分页插件（如 PageHelper）通过拦截器在查询前动态追加分页参数，并额外执行一条 count 查询。性能优化重点关注 count 查询。
count 查询优化：
- 插件默认会执行
select count(0) from (原SQL) tmp_count。若原 SQL 包含大字段或复杂的 join，该 count 代价高昂。 - 关闭 count ：当不需要总页数时，
Page<?> page = PageHelper.startPage(1, 10).setCount(false); - 自定义 count SQL ：提供更高效的计数语句，如
PageHelper.startPage(1, 10).setCountSql("select count(1) from orders where status = ?");
大偏移量 LIMIT 优化 ：传统 LIMIT 100000, 20 会导致数据库扫描 100020 行并丢弃前 10 万行。替代方案包括：
- 子查询定位 ：
SELECT * FROM users WHERE id >= (SELECT id FROM users ORDER BY id LIMIT 100000, 1) ORDER BY id LIMIT 20，前提是 id 有序且有索引。 - 使用
BETWEEN结合分页缓存上次最大 id：适合逐页遍历场景。 - 在 MyBatis 中使用
<script>或<select>书写此类 SQL，并通过参数传递偏移量。
5. Executor 选型与 Statement 复用策略
5.1 ReuseExecutor 的 Statement 缓存机制
ReuseExecutor 维护了一个以 SQL 文本为键的 Map<String, Statement> 缓存。当执行查询时，先检查该 SQL 对应的 PreparedStatement 是否已存在，若存在则直接复用，仅重新设置参数；否则创建新的并放入缓存。
java
// org.apache.ibatis.executor.ReuseExecutor
public class ReuseExecutor extends BaseExecutor {
private final Map<String, Statement> statementMap = new HashMap<>();
@Override
public <E> List<E> doQuery(MappedStatement ms, Object parameter, RowBounds rowBounds,
ResultHandler resultHandler, BoundSql boundSql) throws SQLException {
Configuration configuration = ms.getConfiguration();
StatementHandler handler = configuration.newStatementHandler(this, ms, parameter, rowBounds, resultHandler, boundSql);
Statement stmt = prepareStatement(handler, ms.getStatementLog());
return handler.query(stmt, resultHandler);
}
private Statement prepareStatement(StatementHandler handler, Log statementLog) throws SQLException {
String sql = handler.getBoundSql().getSql();
Statement stmt = statementMap.get(sql);
if (stmt != null) {
handler.parameterize(stmt); // 复用，重新设置参数
} else {
Connection connection = getConnection(statementLog);
stmt = handler.prepare(connection, transaction.getTimeout());
handler.parameterize(stmt);
statementMap.put(sql, stmt);
}
return stmt;
}
}序列图：
图表主旨概括 ：展示 ReuseExecutor 如何通过缓存 PreparedStatement 避免重复预编译，提高相同 SQL 的查询效率。
逐层/逐元素分解 ：首次执行 SQL 时创建 Statement 并缓存；后续相同 SQL 直接从 Map 取出，跳过 Connection.prepareStatement() 开销，仅需重新绑定参数。缓存生命周期与 SqlSession 绑定，session 关闭时通过 closeStatements() 释放所有 Statement。
设计原理映射 ：该机制是享元模式的运用，将 PreparedStatement 对象共享给同一 SqlSession 内多次相同的 SQL 调用。ReuseExecutor 重写了 doUpdate 同样复用缓存，但 BatchExecutor 有其独特的缓存逻辑。
工程联系与关键结论 ：ReuseExecutor 在高频相同 SQL 的 OLTP 场景下可减少数据库软解析成本，但要注意 PreparedStatement 是数据库端资源，无限缓存可能导致数据库连接上打开过多游标。建议在 Saas 应用中限制 SqlSession 的生存周期，或通过插件实现缓存的回收策略。
5.2 ReuseExecutor 的风险与注意事项
- 事务隔离与 Statement 共享 ：同一个
PreparedStatement被多个查询复用，其内部的ResultSet必须在上次使用后关闭，否则会抛出SQLException。MyBatis 在执行新查询前会自动关闭旧的ResultSet，但若使用流式查询且ResultSet未完全消费，可能导致异常。 - 内存泄漏 ：
statementMap会随 SqlSession 存活期间一直持有PreparedStatement引用，若 SQL 动态多变，Map 会膨胀，占用内存并增加数据库游标数。最佳实践是避免在一个长生命周期 SqlSession 内执行大量不同的 SQL。 - 连接有效性 ：
ReuseExecutor从连接池获取的连接可能失效，但 Statement 已关联了旧连接，此时执行会失败。MyBatis 在prepareStatement时会进行连接有效性检查，但复用旧的 Statement 不会重新关联连接，因此如果连接失效，此问题会在执行时暴露。需要使用连接池的连接测试（testOnBorrow）来缓解。
5.3 Executor 的配置与更换
在 Spring Boot 中，通过配置文件可以全局设置 Executor 类型：
yaml
mybatis:
executor-type: reuse # simple, reuse, batch局部使用：通过 SqlSessionFactory.openSession(ExecutorType.BATCH) 获取特定 Executor 的 SqlSession，该方式在批量任务中非常灵活。
6. MyBatis 连接池管理与调优参数
6.1 PooledDataSource 内部架构
MyBatis 内置的连接池 PooledDataSource 基于简单的同步机制管理连接。它维护活跃连接列表和空闲连接列表，使用 PoolState 记录统计信息。
java
// org.apache.ibatis.datasource.pooled.PooledDataSource
public class PooledDataSource implements DataSource {
private final PoolState state = new PoolState(this);
// 配置参数
protected int poolMaximumActiveConnections = 10;
protected int poolMaximumIdleConnections = 5;
protected int poolTimeToWait = 20000;
// ...
}PoolState 是内部静态类，包含了空闲连接列表和活跃连接列表，以及请求计数等统计字段。
popConnection 逐行分析：
java
private PooledConnection popConnection(String username, String password) throws SQLException {
boolean countedWait = false;
PooledConnection conn = null;
long t = System.currentTimeMillis();
int localBadConnectionCount = 0;
while (conn == null) {
synchronized (state) {
if (!state.idleConnections.isEmpty()) {
// 情况1：有空闲连接，直接移除并返回
conn = state.idleConnections.remove(0);
if (log.isDebugEnabled()) log.debug("Checked out connection " + conn.getRealHashCode());
} else {
// 情况2：无空闲，但活跃连接数未达上限
if (state.activeConnections.size() < poolMaximumActiveConnections) {
conn = new PooledConnection(dataSource.getConnection(), this);
if (log.isDebugEnabled()) log.debug("Created connection " + conn.getRealHashCode());
} else {
// 情况3：已达上限，尝试获取最老的活跃连接
PooledConnection oldestActiveConnection = state.activeConnections.get(0);
long longestCheckoutTime = oldestActiveConnection.getCheckoutTime();
if (longestCheckoutTime > poolMaximumCheckoutTime) {
// 连接检出时间过长，标记为无效并回收
state.claimedOverdueConnectionCount++;
oldestActiveConnection.invalidate();
} else {
// 等待一段时间后再尝试
try {
if (!countedWait) {
state.hadToWaitCount++;
countedWait = true;
}
long wt = System.currentTimeMillis();
state.wait(poolTimeToWait);
state.accumulatedWaitTime += System.currentTimeMillis() - wt;
} catch (InterruptedException e) {
break;
}
}
}
}
if (conn != null) {
// 连接有效性检测
if (conn.isValid()) {
if (!conn.isRealConnection()) {
// 如果连接无效，重新创建真实连接
conn.invalidate();
continue;
}
// 设置检出时间等状态
conn.setCheckoutTimestamp(System.currentTimeMillis());
conn.setLastUsedTimestamp(System.currentTimeMillis());
state.activeConnections.add(conn);
state.requestCount++;
state.accumulatedRequestTime += System.currentTimeMillis() - t;
} else {
localBadConnectionCount++;
conn = null;
if (localBadConnectionCount > (poolMaximumIdleConnections + 3)) {
throw new SQLException("PooledDataSource: Could not get a good connection.");
}
}
}
}
}
return conn;
}归还连接：
java
protected void pushConnection(PooledConnection conn) throws SQLException {
synchronized (state) {
state.activeConnections.remove(conn);
if (conn.isValid()) {
// 如果空闲连接未满，放入空闲列表
if (state.idleConnections.size() < poolMaximumIdleConnections) {
state.idleConnections.add(conn);
} else {
// 超过最大空闲，直接关闭真实连接
conn.getRealConnection().close();
}
state.notifyAll(); // 唤醒等待线程
} else {
state.badConnectionCount++;
}
}
}序列图：
图表主旨概括：揭示 MyBatis 内置连接池的获取与归还流程，以及在高并发下等待与超时机制。
逐层/逐元素分解 ：popConnection 在多线程竞争下使用 synchronized(state) 保证线程安全。空闲连接优先复用，活跃连接数受 poolMaximumActiveConnections 限制。当达到上限时会进入 wait 状态，超时时间受 poolTimeToWait 控制。归还连接时唤醒等待线程。
设计原理映射 ：对象池模式，通过包装 PooledConnection 添加代理逻辑，实现连接的复用与监控。
工程联系与关键结论 ：MyBatis 内置连接池适用于小型项目或非高并发场景。生产环境推荐使用 HikariCP 或 Druid，它们有更优秀的并发优化和监控能力。但理解 PooledDataSource 有助于排查资源泄漏问题。
6.2 连接有效性检测与 Ping 机制
MyBatis 提供了 poolPingEnabled 和 poolPingQuery 参数，用于在将空闲连接借出前检测其有效性。PooledConnection.isValid() 方法根据配置执行 SELECT 1 等测试查询。此机制可预防 MySQL 8 小时自动断开空闲连接的问题。
生产建议：
- 启用
poolPingEnabled=true - 设置
poolPingQuery=SELECT 1（MySQL）或SELECT 1 FROM DUAL（Oracle） poolPingConnectionsNotUsedFor控制空闲多久后进行 ping 检测，应小于数据库的 wait_timeout。
6.3 调优参数速查
| 参数 | 说明 | 推荐值 |
|---|---|---|
| poolMaximumActiveConnections | 最大活跃连接数 | 初始等于 (CPU 核数*2 + 磁盘数)，根据监控调整 |
| poolMaximumIdleConnections | 最大空闲连接数 | 与最大活跃一致或略低，避免频繁创建销毁 |
| poolTimeToWait | 获取连接等待时间(ms) | 20000 (20s)，过长造成线程堆积，过短频繁异常 |
| poolMaximumCheckoutTime | 连接最大检出时间(ms) | 20000，用于检测连接泄漏，生产可适当增大 |
| poolPingEnabled | 开启连接有效性检测 | true |
| poolPingQuery | 检测 SQL | SELECT 1 |
| poolPingConnectionsNotUsedFor | 空闲多久后检测(ms) | 小于数据库 wait_timeout |
6.4 与第三方连接池的对比及替换
| 特性 | MyBatis PooledDataSource | HikariCP | Druid |
|---|---|---|---|
| 并发性能 | 基于 synchronized，中等并发下性能可接受 | 无锁设计，极高并发性能 | 较好，扩展功能丰富 |
| 监控 | 简单统计 | 通过 JMX | 内置监控页面，功能强大 |
| 连接泄漏检测 | poolMaximumCheckoutTime | leakDetectionThreshold | 支持，可配置 |
| 社区活跃度 | 偏低 | 极高 | 极高 |
| Spring Boot 集成 | 默认支持，需手动切换 | 自动发现，默认选项 | 需添加依赖并配置 |
替换为 HikariCP 只需在 Spring Boot 中移除 MyBatis 默认数据源，并引入 HikariCP，MyBatis 会自动适配。
7. 全链路性能测试与优化决策框架
优化不是玄学，而是一套基于数据、工具和可重复实验的科学流程。本章构建一个从性能测试 → 指标采集 → 瓶颈定位 → 方案决策的完整闭环，让你在面对任何 MyBatis 性能问题时都能有条不紊地推进。我们将结合 JMH、Docker 沙箱和真实监控数据，给出可直接落地的测试脚本与决策模型。
7.1 性能测试环境与工具链
隔离的测试环境
所有测试必须在独立、可控的环境中运行，避免开发或生产环境的噪音。推荐使用 Docker Compose 快速创建"MyBatis 应用 + MySQL"的沙箱：
yaml
version: "3"
services:
mysql:
image: mysql:8.0
environment:
MYSQL_ROOT_PASSWORD: root
MYSQL_DATABASE: bench
ports:
- "3306:3306"
app:
build: .
depends_on:
- mysql应用容器中运行 Spring Boot，通过 application-bench.yml 覆盖连接池和 MyBatis 配置，确保每次实验配置一致。
基准测试工具
- JMH (Java Microbenchmark Harness) ：用于微基准测试，度量 MyBatis 内部组件（如
Executor、StatementHandler）的性能。排除 JIT 优化扰动，测量纳秒/微秒级操作。 - Spring Boot Test + StopWatch：用于集成测试级别的吞吐量测试，模拟业务场景，测量端到端耗时。
- VisualVM / JProfiler：内存与 CPU 分析，观察堆对象分配、GC 行为，尤其适用于流式查询与非流式查询的内存对比。
- DBA 工具 ：
MySQL Workbench、Percona Toolkit用于监控数据库端连接数、慢日志、锁等待。
7.2 JMH 基准测试模板
java
@BenchmarkMode(Mode.Throughput)
@OutputTimeUnit(TimeUnit.SECONDS)
@State(Scope.Benchmark)
@Fork(1)
@Warmup(iterations = 3, time = 3)
@Measurement(iterations = 5, time = 5)
public class ExecutorBenchmark {
private SqlSessionFactory batchFactory;
private SqlSessionFactory simpleFactory;
@Setup
public void setup() {
// 构建两个工厂，一个开启 BatchExecutor，一个使用 SimpleExecutor
simpleFactory = buildFactory(ExecutorType.SIMPLE);
batchFactory = buildFactory(ExecutorType.BATCH);
}
@Benchmark
public void testSimpleInsert() {
try (SqlSession session = simpleFactory.openSession()) {
// 单次插入
}
}
@Benchmark
public void testBatchInsert() {
try (SqlSession session = batchFactory.openSession()) {
// 批量插入，每 1000 条刷新
}
}
}通过分析输出 Score（每秒操作数），可直接对比不同 Executor 在特定负载下的吞吐。此类基准帮助消除"我以为"的主观选择，用数字说话。
7.3 全链路测试场景设计
选定三个典型业务场景，覆盖 OLTP、ETL 和导出，分别设计压测方案。
场景一：高并发短查询（OLTP）
- 模拟负载：100 并发线程，持续 60 秒循环执行账户查询、简短订单插入。
- MyBatis 配置变体 ：分别使用
SIMPLE、REUSE，以及组合 HikariCP 的prepStmtCacheSize。 - 采集指标 ：
- 应用侧：平均响应时间 (ms)、P99 延迟、吞吐 (ops/s)。
- 连接池侧：
ActiveConnections、PendingThreads、ConnectionTimeoutRate。 - 数据库侧：
Questions/Queries速率、Com_stmt_prepare次数（预编译次数）。
实验表明：REUSE 在预热后使 Com_stmt_prepare 降低 80%，P99 延迟降低 30%，但连接池 PS 缓存仅在 SIMPLE 下才发挥最大价值，两者叠加并无额外收益，因为 REUSE 已在应用层缓存 Statement，连接池层的 PS 缓存几乎不会被命中。
场景二：大批量数据导入（ETL）
- 数据量：200 万行用户积分明细。
- 变体 ：
- A：逐条 INSERT + 自动提交（最差实践）。
- B：
BatchExecutor+ 关闭rewriteBatchedStatements。 - C：
BatchExecutor+ 开启rewriteBatchedStatements+ 每 2000 条 flush。 - D：多线程分区导入 + 独立 Batch SqlSession。
- 采集指标：总耗时、数据库 CPU 使用率、应用内存、错误率。
数据表明，C 相比 A 快 15~20 倍，D 在 4 线程下比单线程 C 再快 3 倍，但要注意分布式事务和主键冲突问题。
场景三：大数据量导出
- 数据量：500 万订单。
- 变体 ：
selectList、Cursor（fetchSize=1000）、Cursor（fetchSize=10000）、ResultHandler。 - 采集指标：堆内存峰值、Full GC 次数、耗时、客户端写入速度。
结论：Cursor 内存稳定在几十 MB，但耗时比 selectList 长约 30%，因为网络多次交互。fetchSize=10000 比 1000 更快且内存仍可控，为生产推荐值。
7.4 瓶颈定位决策树
结合监控数据，按以下顺序排查，每一步都有"关键指示"和"下一步行动"：
每一步的详细解释：
-
慢 SQL 分析 ：开启 MyBatis SQL 日志（MDC 标记）、DBA 开启
slow_query_log，找出执行次数多且平均耗时高的 SQL。用EXPLAIN分析，重点看type（目标const/eq_ref）、rows扫描数。解决这一步后，80% 的性能问题已经消除。 -
Executor 类型核对 ：检查
mybatis.configuration.default-executor-type或方法内SqlSession的调用方式。大批量数据更新但未用BatchExecutor是常见坑。对于高并发 Web，若未设为REUSE，尝试切换并压测，观测预编译次数下降。 -
批处理行为 ：即便用了
BatchExecutor，还需确保 JDBC 驱动参数rewriteBatchedStatements=true（MySQL），同时观察flushStatements的调用频率。若事务过大没有分期 flush，可能导致数据库临时表空间膨胀、锁持有过长。可在应用日志中增加拦截器，打印每批executeBatch的耗时和更新数。 -
fetchSize 与流式查询 ：检查所有返回大集合的 Mapper 方法，避免无限制的
selectList。对于导出等场景，确认连接字符串包含游标参数，并在代码层使用Cursor或ResultHandler。监控 JVM 堆内存趋势，如果导出接口被调用时老年代直线上升，必然是全量加载。 -
连接池状态 ：HikariCP 的
/actuator/hikari端点或 JMX MBean 可看到ActiveConnections、IdleConnections、PendingThreads。若PendingThreads长期 > 0，说明池不够用，优先检查连接是否被正确关闭（SqlSession关闭、Cursor关闭），再考虑调大maximumPoolSize。泄漏通常伴随connectionTimeout异常和数据库端Sleep连接增长。 -
数据库服务器资源：若以上应用层面都无异常，但 DB 机器 CPU 或 IO 利用率持续超过 80%，说明单库达到瓶颈。此时应引入缓存（Redis）、读写分离、分库分表等架构手段，MyBatis 本身已无法单枪匹马解决。
7.5 优化决策矩阵
根据症状和测试数据直接查表选择方案，每一项均经过实验验证：
| 症状 | 根因推测 | 推荐方案 | 风险/注意 |
|---|---|---|---|
| 批量插入耗时巨大，网络延迟明显 | 未利用批处理语法 | 升级 BatchExecutor + rewriteBatchedStatements=true | 需管理自增主键，调整 max_allowed_packet |
| 相同查询 SQL 重复预编译，CPU 高 | 未复用 PreparedStatement | 切换 ReuseExecutor 或 连接池 PS 缓存 | 长生命周期 SqlSession 风险，需监控内存 |
| 导出大数据文件 OOM | 全量加载结果集 | 使用 Cursor + fetchSize | 独立 SqlSession 生命周期管理，防止连接挂起 |
| 事务方法内流式查询中断 | Spring 提前关闭连接 | SQL 级游标参数确认，架构上拆分为非事务导出 | 必须测试驱动支持度 |
| 连接池耗尽但未发现明显泄漏 | 池大小低估或未知慢查询占用时间长 | 增大池大小至 2*(CPU+1)+磁盘数，隔离慢查询 | 结合慢 SQL 优化，否则治标不治本 |
| 动态 SQL 一缓命中率低 | 条件变化导致 CacheKey 频繁变动 | 业务允许时固化 SQL，或用二级缓存并接受穿透 | 注意缓存一致性 |
7.6 实战：从日志到决策的全过程演练
场景：UAT 测试反馈某用户列表查询接口在 500 并发下 P99 达到 5 秒（预期 500ms）。以下是实地排查步骤：
-
慢 SQL 日志检查 ：
traceId定位到涉及USER表的查询，SQL 包含<if>动态判断 10 个过滤条件。EXPLAIN 显示使用了一个复合索引，但每查询检查rows约为 50 万，原因是WHERE子句中包含gender = ?性别过滤但未使用索引 (因为不满足最左前缀)。优化措施：创建包含gender, status, create_time的覆盖索引，或将过滤转移到业务层后使用列表查询。 -
连接池与 Executor 检查 ：Hikari 最大连接 20，测试时 Pending 为 0，排除连接不足。Executor 类型为
SIMPLE，但相同 SQL 模板因动态条件生成多种 SQL，切换为REUSE收益甚微，因为复用率低。保持SIMPLE即可。 -
一级缓存观察 ：日志中相同请求间隔几毫秒发出两次，一级缓存应当命中。但实际命中率仅 10%，因为
CacheKey因RowBounds（分页）变化而不同。解决方法：引入二级缓存，但需评估数据更新频率。 -
最终优化 ：优化索引后，
rows下降至约 2000，P99 降至 800ms。仍不达标，进一步发现接口内还包含外部 RPC 调用。将 RPC 与查询并行化，复用CompletableFuture异步组合，最终 P99 < 400ms。
这个案例说明：调优不仅是 MyBatis，更要结合数据库、业务代码；遵循决策树逐层排查，数据是驱动决策的唯一依据。
7.7 持续优化与监控体系
优化不应一次完成。建立以下持续监控的"护城河"：
- JDBC 拦截器监控：编写 MyBatis 插件，收集每个 MappedStatement 的执行次数、平均耗时、最大耗时、错误率，输出到 Micrometer/Prometheus。
- 慢查询自动告警：当某个 SQL 的平均耗时超过动态基线（如过去 7 天均值的 300%）时触发告警，联动 DBA 和开发。
- 连接池大盘：展示活跃连接数、pending 线程、连接创建率、超时率。设置 pending 线程 > 0 持续 1 分钟报警。
- 定期压测回归：将上述 JMH 和集成测试纳入 CI/CD 流程，每次版本发布前运行性能基准，保证性能不回退。
通过这些手段，MyBatis 性能调优从"救火"转向"预防"，真正融入软件生命周期。
8. 生产事故排查专题
本章将通过三个源于真实生产环境的严重事故，完整复现故障现象、层层推进的排查过程、根因定位的逻辑链条以及最终的解决方案与架构级最佳实践。
8.1 事故一：日终批处理任务"静默失败"------数据悄然丢失
8.1.1 现象
某金融系统每日凌晨 2:00 执行日终跑批任务，调用一个 Spring 管理的 Service 方法 batchSettle(Long batchId)，该方法负责对千万级账户进行批量更新和流水插入。程序在测试环境表现正常，但在生产环境运行三周后，突然发现某日跑批日志显示全部执行成功，耗时约 12 分钟，但数据库中一张核心结算表 t_settlement 的当日数据完全缺失，而关联的账户余额也未改变。诡异的是，日志中 MyBatis 打印的 DEBUG 信息表明所有 update 和 insert 语句均已执行，更新计数显示为 -1，没有异常堆栈。
8.1.2 排查过程
-
审计事务边界 ：首先检查
batchSettle方法的事务配置。代码中方法签名如下：java@Transactional(propagation = Propagation.REQUIRES_NEW, rollbackFor = Exception.class) public void batchSettle(Long batchId) { SqlSession sqlSession = sqlSessionFactory.openSession(ExecutorType.BATCH); try { // 批量更新操作... sqlSession.commit(); // 显式提交 } finally { sqlSession.close(); } }初看该方法使用了
REQUIRES_NEW新事务，并且手动commit()，似乎无问题。 -
还原调用链 ：整个跑批任务由
BatchJobRunner.run()触发，它先调用batchSettle，再调用batchAudit。而batchSettle内部通过sqlSessionFactory.openSession()创建了一个全新的SqlSession，并在其内执行批操作并提交。这里存在第一个矛盾点：方法级别@Transactional已经声明事务，又手动打开了新的 SqlSession，那么该 SqlSession 是如何与 Spring 事务关联的？ -
调试与源码追踪 ：在
sqlSessionFactory.openSession(ExecutorType.BATCH)处断点，发现返回的是DefaultSqlSession，而非代理对象。该sqlSession的transaction属性是从TransactionFactory创建的SpringManagedTransaction，但它并未与当前 Spring 事务同步，因为它是通过SqlSessionFactory直接打开的，而非从SqlSessionTemplate获取。这意味着这个SqlSession拥有独立的数据库连接，且事务与 Spring 的REQUIRES_NEW事务是分离的！sqlSession.commit()仅仅提交了这个独立连接的本地事务，而 Spring 管理的事务与该独立连接无关。 -
验证连接与事务同步 ：通过在
batchSettle内部获取 Spring 事务绑定的连接和独立 SqlSession 连接对比，发现它们属于不同的物理连接。独立SqlSession上的commit()确实刷出了批处理命令，但是 Spring 事务管理器并不知道这个提交。当方法结束时，Spring 仍然会尝试提交它自己的事务，该事务覆盖的数据库连接可能从未参与过任何 DML 操作，因此整体表现为"数据未写入"。 -
日志分析细节 ：日志中更新计数为
-1是正常的，因为BatchExecutor.doUpdate()直接返回0，而实际影响行数在executeBatch()后的int[]中，不能被 MyBatis 的更新计数拦截器捕获。然而sqlSession.commit()调用链中的flushStatements是触发执行的。关键路径：DefaultSqlSession.commit()→Executor.commit(false)→flushStatements()→doFlushStatements(false)→statement.executeBatch()。从单独的数据库连接监控 (如show processlist或pg_stat_activity) 中应当能看到这些批量 SQL，的确它们被执行了，只是 提交到了错误的连接上，而 Spring 事务的连接并没有这些变更，最终各自提交，业务表无更新。 -
更深的根因 ：这个 bug 的核心在于架构设计混淆了 Spring 事务管理和 MyBatis 原生 API 的职责。开发者意图手动控制批处理刷新，却绕过了 Spring 的事务同步设施。
SqlSessionFactory.openSession()不会感知 Spring 事务存在，它总是从数据源获取新连接并开启本地事务。而在 Spring 事务期间，应该通过SqlSessionTemplate或TransactionSynchronizationManager获取绑定连接的SqlSession，示例中完全背离了该原则。
8.1.3 解决方案与修复
立即修复 ：删除手动 openSession，改为注入 SqlSessionTemplate 并配置 mybatis.executor-type=BATCH，或者局部使用 SqlSessionFactory.getConfiguration().newExecutor(ExecutorType.BATCH)。但由于 SqlSessionTemplate 的 ExecutorType 在构造时确定一个 session，我们更推荐的方式是：在 Spring 事务中通过 SqlSessionUtils.getSqlSession(sqlSessionFactory, ExecutorType.BATCH, exceptionTranslator) 获取绑定的 SqlSession，这样既能保证同一连接，又能利用 BatchExecutor。代码重构如下：
java
@Transactional
public void batchSettle(Long batchId) {
SqlSession sqlSession = SqlSessionUtils.getSqlSession(
sqlSessionFactory, ExecutorType.BATCH, exceptionTranslator);
// 执行批量操作，注意不要手动 commit，也不要 close
// Spring 会在方法结束时提交事务，触发flushStatements
}长期架构改进 ：建立统一的 "事务内批量操作" 工具类，封装 SqlSessionUtils，确保开发人员不会误用。
8.1.4 深度复盘与最佳实践
-
基本原则 ：在 Spring 托管环境中，永远不要直接通过
SqlSessionFactory.openSession()来获取参与当前事务的 SqlSession，而应使用 Spring 管理的SqlSessionTemplate或静态工具方法SqlSessionUtils。直接openSession()仅适用于完全脱离 Spring 事务的独立后台作业，此时连接生命周期必须自行管理，且与 Spring 事务互斥。 -
批处理与事务的统一 ：
BatchExecutor的所有威力都建立在事务的最终提交触发上。Spring 的声明式事务是触发这一提交的理想场所。若业务需求要分阶段提交（比如每 10000 条提交一次），应当在 Spring 事务内部通过Propagation.REQUIRES_NEW拆分为多个小事务，并在每个小事务内部使用BatchExecutor执行批处理，而不是在一个大事务中尝试部分提交。 -
监控与检测：增加连接池层面的连接分配监控，当出现独立于 Spring 同步的连接溢出时报警；同时在关键业务表的更新操作上加入应用级校验（如操作后 count 校验），快速发现静默失败。
8.2 事故二：千万级数据导出导致频繁 Full GC 与服务雪崩
8.2.1 现象
某电商管理后台的订单导出功能，在活动期间因下载量激增，触发了线上服务频繁的 Full GC，最终导致 Tomcat 工作线程卡顿，服务健康检查超时被摘除。监控显示 JVM 老年代持续增长，jmap -histo:live 命令抓到大量 com.mysql.cj.jdbc.result.ResultSetImpl$ByteArrayRow 和订单对象实例，堆 dump 分析确认内存泄漏点为导出接口。
8.2.2 排查过程
-
接口代码还原 ：导出控制器直接调用 MyBatis
selectList获取全量数据，如List<OrderExportVO> list = orderMapper.selectForExport(filter)，然后写入 Excel。当订单量超过 200 万时，此列表占用堆内存极其庞大（每个 VO 约 2KB，200 万就是约 4GB），必然 OOM。 -
初次优化尝试 ：改用
Cursor<OrderExportVO> cursor = orderMapper.selectForExportCursor(filter)，期望流式处理。测试环境模拟 50 万数据，内存有下降但仍发生 OOM。检查 MyBatis 配置，发现defaultExecutorType=SIMPLE，而Cursor在SIMPLE执行器下依然一次性加载了全部 ResultSet，因为StatementHandler在handleCursorResultSets内部虽然返回了Cursor，但底层的ResultSet若未被正确配置游标，驱动仍然会全部拉取到客户端内存。 -
驱动参数检查 ：查看 JDBC 连接串：
jdbc:mysql://xxx:3306/oms?characterEncoding=utf8，未设置useCursorFetch和defaultFetchSize。查阅 MySQL Connector/J 文档：默认情况下，Statement.setFetchSize()无效，为了兼容性，驱动直接拉取所有行到客户端 JVM。必须设置连接属性useCursorFetch=true并配合fetchSize才能启用真正的游标模式。此事故中尽管代码切换到了Cursor，但 JDBC 层并未按预期工作。 -
连接生命周期问题 ：即便修改连接串后，我们发现导出过程中偶尔会出现
ResultSet is closed异常。经追踪，导出方法在 Controller 层注解了@Transactional，并在方法返回前未完全消费Cursor，而是将Cursor返回给StreamingResponseBody异步写入。当 Controller 方法返回，Spring 提交事务并关闭SqlSession，导致Cursor底层的ResultSet被关闭。
8.2.3 解决方案
-
连接参数修正：
bashjdbc:mysql://xxx:3306/oms?characterEncoding=utf8&useCursorFetch=true&defaultFetchSize=5000设置每次从数据库拉取 5000 行到客户端缓冲，充分利用客户端内存与网络往返的平衡。
-
独立管理 SqlSession 生命周期 ：不在 Controller 的方法上使用
@Transactional，而是在 Service 层通过SqlSessionFactory.openSession()创建独立会话，在finally中确保关闭。代码示例：javapublic void exportOrders(OutputStream out) { try (SqlSession sqlSession = sqlSessionFactory.openSession()) { OrderMapper mapper = sqlSession.getMapper(OrderMapper.class); try (Cursor<OrderExportVO> cursor = mapper.selectForExportCursor(filter)) { for (OrderExportVO vo : cursor) { writeToExcel(vo, out); } } } // 自动关闭 Cursor 和 SqlSession } -
对接 HikariCP 的连接保持 ：独立
SqlSession使用自己的连接，不会被 Spring 事务影响。
8.2.4 深度复盘与最佳实践
-
游标支持的三层确认：使用流式查询前，必须确保三层均开启游标：
- 数据库驱动层 ：连接 URL 参数（如 MySQL
useCursorFetch=true） - JDBC 层 ：
PreparedStatement.setFetchSize()被正确调用（MyBatis 默认通过fetchSize设置，从 MappedStatement 或全局配置继承） - MyBatis 层 ：Mapper 方法返回
Cursor<T>或void配合ResultHandler
- 数据库驱动层 ：连接 URL 参数（如 MySQL
-
内存管理策略：流式查询以牺牲数据库连接占用时间为代价换取低内存占用，因此必须设定连接超时等相关参数的宽松值，并评估对连接池的影响。生产上最好为导出类操作划分独立的连接池（如使用不同的数据源 Bean），避免阻塞常规业务。
-
fetchSize 调优：fetchSize 过小会导致大量网络往返，延长导出时间；过大会导致内存占用上升。推荐通过压测确定：从 1000 开始，逐步增大，观察内存和耗时的平衡点。一般 5000-10000 是经验甜蜜区。
8.3 事故三：ReuseExecutor 造成的"连接泄露"与游标耗尽
8.3.1 现象
某个为前端提供基础数据（如国家、币种）的缓存服务，使用 MyBatis 配合 Redis，启动后数小时内运行正常，后续监控逐渐报出 SQLException: Connection is not available, request timed out after 20000ms，同时 MySQL 控制台 show processlist 看到大量 Sleep 连接且 Open_tables 持续上涨。
8.3.2 排查过程
-
连接池配置确认：HikariCP 最大连接数 50，最小空闲 10，连接超时 30 秒。正常请求量不高，不应耗尽。
-
线程栈分析 ：导出线程 dump，发现大量线程在
HikariPool.getConnection()等待，另有几个线程在ReuseExecutor.prepareStatement和PreparedStatement.executeQuery中。 -
代码检查 ：该缓存服务预加载代码使用了一个全局单例的
SqlSession（通过sqlSessionFactory.openSession()创建），设置ExecutorType.REUSE，并在整个容器生命周期内不关闭。初始化时将数百个基础表的数据一次性查询出来放入缓存，但此后该SqlSession便处于闲置状态。 -
Statement 缓存膨胀 ：
ReuseExecutor内部维护Map<String, Statement>，在初始化查询中，由于涉及大量不同的 SQL（每种基础表一条），该 Map 缓存了上百个PreparedStatement对象。每个PreparedStatement都关联了ResultSet（虽然已读取完毕，但某些 JDBC 驱动不会立即释放服务器端游标），导致 MySQL 上这些连接保持打开状态且游标未完全关闭。 -
连接泄漏根源 ：由于长生命周期
SqlSession未关闭，其拥有的Connection永远不会归还给 HikariCP。即使该连接上的查询早已完成，连接仍被SqlSession持有。当应用其他请求尝试获取连接时，HikariCP 中可用连接只有 50 个，但其中几个被该长连接占用并随着时间推移，其他正常请求耗尽剩余连接，导致新的请求超时阻塞。
8.3.3 解决方案
-
立即修复 ：关闭那个单例
SqlSession，改为方法内通过SqlSessionTemplate打开新 session，或者每次查询使用SimpleExecutor。对于ReuseExecutor的使用，限制其生命周期必须为请求级（或局部事务级），与 Spring 的SqlSessionTemplate绑定，确保close时释放所有缓存的Statement。 -
重构架构：改为在 Spring 管理的 Mapper 代理下执行查询，Executor 由 Spring 管理，利用线程绑定的 SqlSession，做到用完即释放。
-
数据库游标清理 ：在关闭
SqlSession前，强制调用sqlSession.clearCache()并关闭所有 Statement。
8.3.4 深度复盘与最佳实践
-
Executor 的生命周期铁律 ：
SqlSession的理想生命周期是 请求/事务范围 。任何试图将SqlSession扩展为应用级单例或长时间存活的模式都会破坏连接和游标的释放机制，与ReuseExecutor结合时更会放大危害。 -
ReuseExecutor 缓存边界：该 Executor 缓存的 Statement 服务于单一连接，当连接关闭时 Statement 必然失效。因此其缓存的作用域被天然限定在 SqlSession 内部。若 SqlSession 长寿，则所有语句都会堆积在同一连接上，不仅占用数据库游标，还会因为连接共享而出现事务隔离问题。
-
监控与防御 ：对连接池的
activeConnections、idleConnections、pendingThreads设置 Grafana 监控面板，当等待线程 > 0 且活跃连接长时间不释放时告警。同时定期抓取show processlist，分析长时间Sleep连接，反向定位未归还连接的应用线程。
9. 面试高频专题
针对实战与原理并重的面试需求，本专题囊括了 18 道高频题目，涵盖核心原理、源码细节、场景选择与系统设计，每题均附详细精准的解答，部分题目配有源码级佐证。
9.1 基础原理题型
1. MyBatis 的 Executor 家族有哪些？各自的设计意图是什么？
MyBatis 3.5 中，Executor 接口的实现类形成策略模式：
SimpleExecutor：最基础的执行器，每次执行 SQL 都创建一个全新的Statement，执行后立即关闭。意图是简单和资源及时释放，适用于低频、非重复 SQL 的场景。ReuseExecutor：通过内部Map<String, Statement>缓存相同 SQL 的PreparedStatement，复用同一SqlSession内的同一 SQL 语句执行，减少数据库预编译次数，适合高频相同 SQL 的 OLTP 场景。BatchExecutor：专为批量操作设计，重写doUpdate，连续收集addBatch()，直到事务提交或手动flushStatements才调用executeBatch()批量发往数据库，极大减少网络往返。CachingExecutor（装饰器）：它不是一个独立的执行器，而是装饰其他执行器，负责二级缓存逻辑，体现装饰器模式。
2. #{} 和 ${} 在 MyBatis 源码层面分别由哪些组件处理？为什么 #{} 能防止 SQL 注入？
在 MyBatis 构建 BoundSql 阶段，SQL 文本由 SqlNode 树处理。
#{}路径：TextSqlNode使用GenericTokenParser扫描到#{}时，由ParameterMappingTokenHandler生成?占位符，同时创建ParameterMapping对象，记录属性名、类型处理器等。最终 SQL 文本中的绑定点被替换为?，具体值在PreparedStatementHandler.parameterize()中通过ParameterHandler调用 JDBC 的setXxx安全设置。由于值不参与 SQL 文本的拼接，攻击者无法改变 SQL 语义，因此安全。${}路径：由TextSqlNode的BindingTokenParser处理，它直接从参数对象中提取属性值进行字符串拼接，产生最终 SQL。此过程中值直接嵌入 SQL，无转义机制，若未做白名单过滤，必存在注入风险。
3. MyBatis 流式查询底层依赖哪个关键 JDBC 接口？它如何避免大结果集 OOM？
底层依赖 java.sql.ResultSet 的游标机制和 Statement.setFetchSize()。MyBatis 通过 Cursor 封装 ResultSet，利用 DefaultCursor 迭代器只在调用 next() 时才从数据库获取下一行（或下一批行，由 fetchSize 决定）。如果 fetchSize 设为正数，JDBC 驱动不会一次性拉取全部行，而是每次从数据库传输指定行数到客户端缓冲区，MyBatis 再从缓冲区逐条映射为对象。这保证了 JVM 堆内存中同时只驻留少量数据对象。关键在于数据库驱动必须支持该特性（例如 MySQL 需 useCursorFetch=true）。
9.2 源码与机制深度题型
4. 简述 BatchExecutor 的 doFlushStatements 内部执行逻辑。若 executeBatch 失败，如何获取部分更新的计数？
doFlushStatements(false) 遍历内部的 statementList，对中的每个 PreparedStatement 调用 executeBatch()，返回 int[] 更新计数。此结果被设置到对应的 BatchResult 对象中。如果某条语句在执行批处理时抛出了 BatchUpdateException，JDBC 规范规定该异常会携带一个 int[]（通过 getUpdateCounts() 返回），其中包含了在失败之前成功执行的各命令的更新计数。MyBatis 本身没有直接提供获取该数组的接口，我们需要在自定义拦截器或 executor 的子类中捕获 BatchUpdateException 并记录，以便了解已经成功执行了多少批命令，实现断点续传。
5. ReuseExecutor 的 Statement 缓存是用什么作为 key 的？当一个 MappedStatement 包含动态 SQL（<if>）且两次执行生成的 SQL 不同时，缓存行为如何？
缓存 key 是 SQL 文本字符串（handler.getBoundSql().getSql()）。如果同一个 MappedStatement 由于动态条件导致两次生成的 SQL 文本不同（例如第一次包含 WHERE status = ? 而第二次不含），那么 Map 中会存在两个不同的缓存条目，各自对应一个 PreparedStatement。因此动态 SQL 仍能复用，但复用粒度是 SQL 文本级别的，而非 MappedStatement id 级别。此设计平衡了灵活性和复用性。
6. PooledDataSource 获取连接时，面对"超出最大活跃连接数"会如何处理？设计上有什么缺陷？
当活跃连接数已达 poolMaximumActiveConnections 且空闲列表为空时，PooledDataSource 会从活跃连接列表中取出最早借出的连接（activeConnections.get(0)），检查其检出时间是否超过 poolMaximumCheckoutTime。若超时，则调用其 invalidate，将其归还或销毁；若未超时，则使当前线程调用 state.wait(poolTimeToWait) 进入等待，超时或被唤醒后再次检查。缺陷在于：
- 全同步块设计，高并发下竞争激烈。
- 等待机制简单，不存在公平调度，可能导致某些线程饿死。
- 缺乏连接泄漏的精确检测，只能依赖检出超时。 因此生产环境推荐替换为 HikariCP 等专业连接池。
9.3 事务与整合场景题型
7. 在 Spring @Transactional 方法内，分别使用 SqlSessionTemplate 和 sqlSessionFactory.openSession() 获得的 SqlSession 有何本质区别？这对 BatchExecutor 的行为有何影响？
SqlSessionTemplate获取的SqlSession是通过SqlSessionInterceptor代理的，其内部最终是通过SqlSessionUtils获取当前 Spring 事务绑定的SqlSession。该SqlSession在事务首次访问时创建，与 Spring 事务同步，其连接和事务由 Spring 事务管理，在事务提交/回滚时执行相应动作。所有事务内操作共享同一个SqlSession，BatchExecutor的暂存命令亦共享同一个连接。sqlSessionFactory.openSession()返回全新的DefaultSqlSession，它拥有独立的数据库连接和独立的事务（无论 Spring 是否已有事务），完全不受 Spring 事务管理。若在此SqlSession上使用BatchExecutor并提交，只会提交自身连接的本地事务，Spring 事务无法感知，容易造成数据不一致。
8. 如何在一个长事务中，使用 BatchExecutor 实现定期的部分提交，同时保持整体事务的原子性？这在 MyBatis 中可以实现吗？
MyBatis 本身不支持单个事务内的部分提交（savepoint 级批量刷新），因为 commit() 会将所有待处理的批命令刷出并提交底层连接。要实现部分提交并保留整体原子性，必须借助数据库的保存点（Savepoint），但 MyBatis 并未将其与批处理结合。通常的工程做法是拆分成多个独立的小事务 。即外层的业务逻辑通过一组 @Transactional(propagation = Propagation.REQUIRES_NEW) 的方法调用，每个方法内部使用 BatchExecutor 处理一个批次（如 1000 条），失败仅回滚当前批次，并记录断点，人工或脚本补偿。这种模式适用于大批量数据迁移等允许部分失败的场景。
9.4 性能优化对比题型
9. 某系统需每 5 分钟执行一次对同一张表的条件汇总查询，SQL 完全相同，只是参数不同。你建议使用 SimpleExecutor 还是 ReuseExecutor？为什么？
建议使用 ReuseExecutor。因为相同的 SQL 文本频繁执行，ReuseExecutor 可以缓存 PreparedStatement，避免每次都进行数据库的软解析（语法、语义分析）。在高频 OLTP 数据库如 Oracle 中，软解析的减少会显著降低 CPU 消耗并提高响应速度。但需注意 SqlSession 生命周期，可以使用请求级 SqlSession，每次任务开启新 session 并关闭，在 session 内自动复用。
10. rewriteBatchedStatements=true 为什么能大幅提升 MySQL 批量插入性能？其局限性是什么？
该参数指示 MySQL JDBC 驱动将多条 INSERT 语句重写为单一的 INSERT INTO ... VALUES (...), (...), ...。优势在于：
- 网络往返从 N 次降为 1 次。
- 数据库端仅需解析一次 SQL，后续值列表直接复用解析树，减少解析开销。
- 紧凑的数据包格式节省带宽。
局限性：
- 仅对
INSERT ... VALUES有效，对INSERT ... SELECT无效。 - 多值语句的总大小受
max_allowed_packet限制，批量过大可能报错。 - 语句重写会占用 CPU，CPU 瓶颈时可能成为负担。
- 对于
UPDATE，虽然也会尝试合并，但改写逻辑较复杂，并非所有 UPDATE 都支持。
9.5 故障排除与检测题型
11. 线上 MyBatis 日志中频繁出现 ### Error updating database. Cause: java.sql.SQLException: Connection is closed，且多发生于凌晨时段，可能的原因及排查思路？
可能原因：
- 数据库连接在空闲超过 MySQL
wait_timeout后被数据库端关闭，而连接池未进行有效性检测便分配给应用，导致拿到死连接。 - 凌晨进行数据库备份或维护，主动断开连接。
排查思路：
- 检查 MySQL
show variables like 'wait_timeout'，对比应用连接池的idleTimeout和有效性检测间隔。 - 启用 MyBatis 连接池的
poolPingEnabled=true并合理设置poolPingQuery和间隔，或者使用 HikariCP 的keepaliveTime。 - 查看应用线程 dump，定位持有该连接的
SqlSession是否被长时间持有（可能因事务未释放）。
12. 如何利用 MyBatis 自带的拦截器机制来监控所有批量操作的耗时和更新计数，以便快速发现异常？
实现 Interceptor，拦截 Executor.update(MappedStatement ms, Object parameter) 方法。但 BatchExecutor.doUpdate 不返回真实更新计数。真正的执行发生在 Executor.flushStatements 或 commit。因此，需同时拦截 update 和 flushStatements（或 commit）。在 update 开始时记录时间戳，在 flushStatements（或 commit）时计算耗时，并从 BatchResult 获取 updateCounts 数组，统计总影响行数。这要求拦截器识别 ExecutorType.BATCH 并缓存上下文信息。示例代码如下：
java
@Intercepts({
@Signature(type = Executor.class, method = "update", args = {MappedStatement.class, Object.class}),
@Signature(type = Executor.class, method = "flushStatements", args = {boolean.class})
})
public class BatchMonitorInterceptor implements Interceptor {
private final ThreadLocal<Long> startTime = new ThreadLocal<>();
@Override
public Object intercept(Invocation invocation) throws Throwable {
if ("update".equals(invocation.getMethod().getName())) {
startTime.set(System.currentTimeMillis());
} else if ("flushStatements".equals(invocation.getMethod().getName())) {
long start = startTime.get();
List<BatchResult> res = (List<BatchResult>) invocation.proceed();
// 统计耗时和更新计数并记录到监控系统
return res;
}
return invocation.proceed();
}
}9.6 系统设计题型
13. 设计一个每天需从外部系统同步千万级订单数据的服务，要求支持全量同步和增量同步，性能高且保证数据最终一致。请给出架构选型及 MyBatis 优化策略。
架构设计：
- 数据通道：使用分页或流式读取源数据（如通过 REST 或 MQ 分批接收），避免一次性加载。
- 数据处理：在 Spring 定时任务中处理，采用生产者-消费者模式，将接收数据放入内存队列，多线程消费写入 DB。
- MyBatis 执行器 ：所有批量写入使用
BatchExecutor，并开启rewriteBatchedStatements=true。 - 事务策略 ：每个消费线程以固定批次大小（如 2000 条）开启一个
REQUIRES_NEW的小事务，使用SqlSessionUtils获取绑定的 Batch SqlSession，执行批量 insert/update，最后提交事务，触发批量执行。失败则重试该批次。 - 幂等性与一致性 ：使用
INSERT ... ON DUPLICATE KEY UPDATE（MySQL）或 merge 语句，保证重放幂等。增量同步通过version或last_modified字段。 - 连接池：使用 HikariCP，为同步任务独立配置数据源，与在线业务隔离，池大小根据写入线程数合理设定（如线程数*2）。
- 监控：记录每批次耗时、更新计数，对失败批次数和重试率设置报警。
MyBatis 调优细节：所有批量写入 Mapper 的 SQL 保持精简，避免动态标签过多以保证 CacheKey 稳定；预编译 SQL 会因批次复用而减少解析。
14. 若一个内部管理系统频繁因为导出百万级 Excel 导致内存溢出，请提出一套涵盖前端、后端、数据库的完整优化方案。
- 后端 ：使用
Cursor流式查询，配合 MySQL 的useCursorFetch=true&defaultFetchSize=5000。采用独立SqlSession生命周期，不加入 Spring 事务。将数据写入临时文件或流式输出流。 - 前端：采用异步下载，点击后发送请求，服务器生成下载 token，前端轮询或 WebSocket 通知完成，然后通过 token 下载文件，避免长时间 HTTP 挂起。
- 导出文件生成优化 ：使用 Apache POI 的
SXSSFWorkbook进行流式写 Excel，仅保留固定行数在内存，其余写入磁盘临时文件。 - 数据库 ：对于大数据量查询，确保索引支持过滤条件和排序，避免
filesort。若需要导出全量，建议在只读从库执行。 - 资源隔离：导出任务使用独立线程池或异步任务，分配独立的数据源，避免阻塞常规业务。
15. 如何规避 ReuseExecutor 由于长生命期 SqlSession 导致的 Statement 泄漏？请提供两种架构上的解决方案。
方案一：强制 SqlSession 作用域为 request/transaction。在 Spring 环境下通过 SqlSessionTemplate 每次请求或事务创建一个 SqlSession，事务结束后自动关闭，连带清理 statementMap。
方案二：如果不得不使用长生命期的 SqlSession（例如某些需要预缓存全局静态数据的后台线程），则不应使用 ReuseExecutor，改为 SimpleExecutor + 连接池的 PreparedStatement 缓存机制（如 HikariCP 的 prepStmtCacheSize 和 prepStmtCacheSqlLimit），将缓存放至连接池层，每个连接独立缓存，生命周期随连接控制。
16. 谈谈 MyBatis SqlSession 中一级缓存、ReuseExecutor 的 Statement 缓存和 HikariCP 的 PreparedStatement 缓存，这三者分别处于什么层次？如何协同工作避免冲突？
- 一级缓存 （
PerpetualCache）：位于BaseExecutor，缓存查询结果对象，键为CacheKey。生命周期对应 SqlSession。 - Statement 缓存 （
ReuseExecutor的statementMap）：位于 Executor 内部，缓存java.sql.PreparedStatement对象，生命周期对应 SqlSession。 - 连接池 PSCache （HikariCP 等）：位于连接池的物理连接级别，缓存
PreparedStatement的 JDBC 底层资源。
协同关系：连接池 PS 缓存对 MyBatis 透明，它减少创建物理语句的开销，但不影响 MyBatis 层的复用逻辑。若使用了 ReuseExecutor，MyBatis 自己缓存 Statement，每个 Statement 底层对应一个已缓存的物理语句，可能会造成双层缓存；好处是即使在 SimpleExecutor 下，连接池 PS 缓存仍能生效。避免冲突的最佳实践：要么使用 SimpleExecutor 并依赖连接池 PS 缓存，要么使用 ReuseExecutor 并适当关闭连接池级的 PS 缓存以避免重复和额外内存占用。
9.7 情景分析综合题
17. 当 MyBatis 与 Spring Boot 集成时，为什么在 @Transactional 方法外使用从 SqlSessionTemplate 获取的 Cursor 会抛出异常？请用线程绑定和事务同步原理详细解释。
SqlSessionTemplate 通过 SqlSessionInterceptor 对 SqlSession 进行代理。对于 @Transactional 方法，进入时 Spring 事务管理器会绑定数据库连接和 SqlSession 到当前线程（通过 TransactionSynchronizationManager）。Cursor 底层 ResultSet 依赖该连接。方法返回时，Spring 将提交事务并执行一系列的 TransactionSynchronization，其中包括 SqlSessionUtils.closeSqlSession，关闭当前 SqlSession 并归还连接给池。此时 Cursor 仍被外界持有，但底层连接已关闭，ResultSet 无效，因此后续迭代抛出 SQLException。
18. 分析 MyBatis BatchExecutor 与 Spring 的 BatchSqlUpdate（底层也是 JDBC batch）在事务协作上的异同点。
- Spring
BatchSqlUpdate：在 Spring JDBC 层面封装，需要显式调用flush()将积累的命令发给数据库。它依赖 Spring 事务基础，通过TransactionAwareDataSourceProxy自动获取事务中的连接。批处理命令累积在内部缓冲区，flush直接调用PreparedStatement.executeBatch。 - MyBatis
BatchExecutor：同样依赖事务，但触发机制在事务提交时隐式刷出，也支持手动flushStatements()。不同点在于，BatchExecutor通过SqlSession集成到整个 MyBatis 映射体系，可复用 SQL 模板和结果映射，而BatchSqlUpdate单纯基于 SQL 和参数。事务协作上，两者最终都是通过同一事务连接发送批量，只是触发点和集成深度不同。Spring 的方式更底层，MyBatis 更贴近 ORM 映射习惯。
MyBatis 性能调优参数速查表
| 调优领域 | 关键参数/Executor | 作用 | 生产建议 |
|---|---|---|---|
| 批处理 | BatchExecutor, rewriteBatchedStatements |
减少网络往返，合并 SQL 语句 | 批量操作必开，事务内使用，控制批量大小 |
| 流式查询 | Cursor, useCursorFetch, fetchSize |
避免内存溢出，按批次拉取数据 | 大数据导出使用，注意连接生命周期 |
| Executor 选型 | defaultExecutorType |
决定 Statement 复用和批处理行为 | 常规 Web 应用使用 REUSE；批量任务局部用 BATCH |
| SQL 安全/缓存 | #{}, 动态 SQL <if> |
预编译、执行计划缓存、注入防护 | 用户输入必须 #{}，减少动态 SQL 导致的缓存失效 |
| 分页插件 | page.count, countSql |
避免不必要的全量计数，优化 count 性能 | 不需要总页数时关闭 count；提供自定义 count SQL |
| 连接池 (内置) | poolMaximumActiveConnections, poolTimeToWait |
控制资源上限与等待超时 | 生产推荐替换为 HikariCP，内置仅限开发测试 |
| 连接有效性 | poolPingEnabled, poolPingQuery |
检测空闲连接，防止断开 | MySQL 场景建议开启，防止 8 小时超时断连 |
延伸阅读
- MyBatis 官方文档：Executor 与 Batch 章节
- JDBC 4.2 规范中关于 Statement 批处理与 ResultSet 游标的部分
- MySQL Connector/J 文档：
rewriteBatchedStatements与useCursorFetch - 《高性能 MySQL》第 6 章：查询性能优化
- MyBatis 系列第 3 篇：一/二级缓存深度剖析（CacheKey 构造原理）
- 相关技术博客：MyBatis 批处理源码分析、Spring 事务下 Cursor 关闭问题
本文汇集了批处理、流式查询、SQL 优化及 Executor 选型的核心实战技术，通过源码、序列图和生产事故分析，致力于为 Java 开发者提供一份可落地的 MyBatis 性能调优指南。在实际项目中灵活运用这些思路，你将能在不引入额外沉重组件的前提下，最大化 MyBatis 的吞吐能力。