Spring Boot 1.5.10中autocommit=true的利弊及配置作用确认问询

针对你提到的Spring Boot 1.5.10.RELEASE + PostgreSQL 9.5.6场景下的autocommit问题，我结合Spring和Hibernate的特性给你详细梳理下：

优势： #

• 简化单操作逻辑：对于不需要事务的独立SQL（比如单条查询、单条更新），自动提交省去了手动管理事务的代码，快速实现基础数据操作。
• 降低入门成本：新手不用纠结事务边界，能快速完成简单功能开发。

劣势： #

• 破坏数据一致性：如果有多个关联操作（比如先插用户再插订单），autocommit=true会让每个SQL单独提交，一旦中间步骤失败，前面的操作无法回滚，直接导致数据不一致。
• 性能损耗明显：每次SQL都触发一次提交，频繁的提交会增加数据库的IO开销，批量操作时性能下降尤为显著。
• 排查问题困难：遇到数据异常时，每个操作都是独立事务，很难追踪到故障的根源步骤。

结论是：不会被完全覆盖，但在Spring事务管理生效的场景下会被接管，分两种情况看：

• 当方法被@Transactional注解标记时：Spring会接管整个事务的生命周期，此时不管数据源的autocommit是true还是false，Spring都会临时将当前连接的autocommit设为false，确保多个SQL在同一个事务中执行，事务结束后再恢复数据源的默认autocommit设置。这种情况下，数据源的autocommit配置不会直接生效，但会作为事务结束后的恢复值。
• 当方法没有@Transactional注解时：Hibernate会继承数据源的autocommit设置，每个SQL操作会自动提交（如果autocommit=true），但这种方式不符合Hibernate的最佳实践，因为Hibernate推荐所有操作都在事务中执行，无事务的操作可能会引发潜在的会话问题。

所以你说的“完全不起作用”是不准确的，它在非事务场景下还是会生效，只是事务场景中被Spring临时接管了。

在你的Spring Boot + PostgreSQL环境中，autocommit分为两层含义：

1. 数据源默认配置：这是你在数据源配置（比如HikariCP的spring.datasource.hikari.auto-commit）中设置的初始值，决定了连接池创建新连接时的默认自动提交状态。
2. 连接的实时状态：
   • 执行@Transactional方法时，Spring事务管理器会临时将当前连接的autocommit改为false，确保事务内的所有SQL都在同一个事务中，直到方法执行完成后提交或回滚，再把连接的autocommit恢复为数据源的默认值（也就是你配置的true）。
   • 你调试看到的autocommit=true，大概率是查看的数据源的配置值，或者是事务执行完成后连接恢复的状态。如果在@Transactional方法中间打断点查看当前连接的autocommit，应该会看到它被临时设为false。
   • 无@Transactional的测试方法中，连接会直接使用数据源的autocommit=true，每个SQL执行后自动提交。

内容的提问来源于stack exchange，提问作者mommcilo