关闭自动提交本身不提升性能，但为批量执行和事务控制提供前提；配合addBatch()与executeBatch()可减少网络往返、优化执行计划、降低IO开销。
在 JDBC 中关闭自动提交（setAutoCommit(false)）本身不直接“提升性能”，但它为真正能提速的操作——比如批量执行和事务控制——提供了前提。单独关掉自动提交不会让单条 SQL 变快，反而可能因未及时提交而延长锁持有时间；它的价值在于配合批量操作或逻辑组合时，显著减少网络往返、避免中间状态提交、提升吞吐量。
为什么关闭自动提交是批量提速的关键一步
数据库默认开启自动提交，意味着每执行一条 INSERT、UPDATE 或 DELETE，JDBC 就会立即向数据库发一次提交请求（commit），引发日志刷盘、锁释放、事务结束等开销。而批量插入 1000 条数据时，如果保持自动提交，就是 1000 次独立事务 —— 网络延迟叠加、IO 频繁、锁竞争加剧。
关闭自动提交后，你可以把这 1000 条操作“打包”成一个事务，只在最后调用一次 commit()，从而：
- 将多次 round-trip 合并为一次提交通信
- 让数据库优化器对整批语句做统一执行计划
- 减少 redo log 刷盘次数（尤其在支持组提交的引擎如 InnoDB 中）
- 避免中间某条失败导致部分数据已提交的脏状态
正确关闭 + 批量执行的典型写法
关键不是只调 setAutoCommit(false)，而是搭配 addBatch() 和 executeBatch() 使用：
Java 接口排错助手
下载
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
立即学习“Java免费学习笔记（深入）”；
- 先获取
Connection，立刻调用conn.setAutoCommit(false) - 使用
PreparedStatement（推荐）或Statement，反复调用addBatch()添加 SQL - 调用
executeBatch()一次性执行全部语句 - 成功则
conn.commit()；异常则conn.rollback() - 最后务必
conn.close()（建议配合 try-with-resources）
示例片段：
try (Connection conn = dataSource.getConnection()) {
conn.setAutoCommit(false);
String sql = "INSERT INTO users(name, email) VALUES (?, ?)";
try (PreparedStatement ps = conn.prepareStatement(sql)) {
for (User u : userList) {
ps.setString(1, u.getName());
ps.setString(2, u.getEmail());
ps.addBatch();
}
ps.executeBatch(); // 一次发送全部
conn.commit(); // 一次提交
} catch (SQLException e) {
conn.rollback(); // 出错整体回滚
throw e;
}
}
配套优化才能真正发挥效果
光关自动提交不够，还需注意这些细节：
-
预编译缓存开启：在连接 URL 或连接池配置中启用
cachePrepStmts=true，避免重复解析 SQL - 批量大小合理：通常 100–1000 条/批较稳；太大易 OOM 或触发数据库超时；太小收益不明显
- 连接池配合：用 HikariCP 等高性能池，避免 getConnection() 成瓶颈；确保池支持事务传播
- 避免长事务：大批量处理时，可分段提交（例如每 500 条 commit 一次），防止锁表或 WAL 压力过大
常见误区提醒
以下做法容易适得其反：
- 关闭自动提交但没配批量，仍用循环执行单条
executeUpdate()→ 性能更差（事务未利用，还多了一次 rollback/commit 开销） - 忘记
commit()或rollback()→ 连接挂起、连接池耗尽、数据库锁堆积 - 在查询（
SELECT）场景下盲目关自动提交 → 对只读操作无意义，还增加事务管理负担 - 多线程共用一个
Connection并关闭自动提交 → 线程安全问题，事务互相干扰
