Spring-JDBC为何用set autocommit=0而非start transaction开启事务？效率对比

• 遵循JDBC规范，保证跨库兼容性：JDBC API原生定义了Connection.setAutoCommit(boolean)方法作为控制事务的标准方式，而START TRANSACTION属于SQL方言，不同数据库的语法存在差异（比如PostgreSQL用BEGIN，Oracle用SET TRANSACTION）。Spring作为通用框架，优先采用JDBC标准API，避免因数据库方言差异导致的兼容性问题。

• 适配连接池的连接复用逻辑：在连接池场景下，连接会被重复利用。如果用START TRANSACTION开启事务，若事务结束后未正确清理状态，归还到池中的连接可能残留未关闭的事务，影响后续使用。而Spring通过set autocommit = 0切换手动提交模式时，会记录原自动提交状态（代码中的setMustRestoreAutoCommit(true)），事务结束后自动恢复该状态，确保连接归还到池时回到默认的自动提交状态，避免连接污染。

• 便于框架统一管控事务生命周期：set autocommit = 0是将连接切换到手动提交模式，后续所有SQL默认纳入同一事务，直到执行COMMIT/ROLLBACK并恢复自动提交。这种程序化的状态切换更贴合Spring事务的传播机制和边界控制逻辑，框架能可靠地掌控事务从开启到结束的全流程，包括连接状态的修改与恢复，比执行SQL语句更便于统一管理。

• 避免驱动层状态不一致问题：部分数据库驱动执行START TRANSACTION后，不会同步更新连接的内部状态标识，导致Spring无法准确判断当前事务状态。而调用Connection.setAutoCommit(false)是通过驱动API直接修改连接状态，驱动会同步更新内部标识，Spring能可靠获取连接的事务状态，避免出现逻辑不一致。

效率差异主要取决于数据库实现，以主流的MySQL InnoDB为例：

• 单次事务开销几乎无差异：set autocommit = 0和START TRANSACTION底层逻辑一致，都会启动新事务、创建Undo日志和锁结构，单次操作的性能开销可以忽略。

• JDBC API调用的额外优化：Spring是通过JDBC API调用setAutoCommit(false)而非直接执行set autocommit = 0的SQL语句，多数驱动会将这个API调用优化为本地操作（无需发送SQL到数据库服务器），相比执行START TRANSACTION的SQL，减少了一次网络往返和SQL解析的开销，在高并发场景下这种差异会被放大。

• 连续事务场景的差异：若未恢复自动提交状态，set autocommit = 0模式下COMMIT结束当前事务后会自动开启下一个；而START TRANSACTION每次都需要显式启动新事务。但Spring在事务结束后会恢复自动提交状态，所以在Spring的使用场景中，这种差异不会体现。

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