mysql中的自动提交与手动提交事务的区别_技术教程

MySQL默认AUTOCOMMIT=1，每条DML语句自成独立事务；设autocommit=0后需显式COMMIT/ROLLBACK，否则连接关闭时回滚，且SELECT也受事务快照影响。

MySQL 默认是自动提交模式

MySQL 连接建立后，默认开启 AUTOCOMMIT=1，这意味着每条 INSERT、UPDATE、DELETE 语句都会立即写入磁盘并持久化，无法回滚。这不是“事务没生效”，而是每个语句自己构成了一个独立事务。

验证当前状态：

SELECT @@autocommit;

返回 1 表示开启，0 表示关闭。

自动提交下执行 START TRANSACTION 或 BEGIN 会临时关闭自动提交，进入手动事务模式，直到 COMMIT 或 ROLLBACK
自动提交关闭后（SET autocommit = 0），所有 DML 都必须显式 COMMIT 才能生效，否则连接断开时自动回滚
DDL 语句（如 CREATE TABLE、ALTER TABLE）在大多数存储引擎中会隐式触发 COMMIT，即使在事务中执行也会立刻提交

手动提交事务必须显式控制生命周期

手动提交不是“开启事务”就完事了，它要求你对整个事务边界有明确判断。常见错误是只写 START TRANSACTION 却忘了 COMMIT，结果数据始终处于未提交状态，其他连接不可见，连接关闭后丢失。

典型流程：

START TRANSACTION;
INSERT INTO users (name) VALUES ('Alice');
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
-- 若中间某步失败（比如余额不足），需主动 ROLLBACK
COMMIT; -- 或 ROLLBACK;

COMMIT 后才真正写入磁盘（取决于 innodb_flush_log_at_trx_commit 配置）
ROLLBACK 会清除所有未提交的变更，包括临时表、锁、自增 ID 预分配（InnoDB 中自增 ID 不回滚）
长事务不提交会持续持有行锁/间隙锁，容易引发锁等待甚至死锁

autocommit=0 时，普通查询也受事务影响

很多人以为只有 DML 才进事务，其实只要 autocommit=0，哪怕只执行一条 SELECT，也会开启一个隐式事务（InnoDB 中称为“一致性读视图”）。这会影响 MVCC 行为和锁粒度。

执行 SELECT ... FOR UPDATE 或 SELECT ... LOCK IN SHARE MODE 会加锁，且锁持续到 COMMIT 或 ROLLBACK
纯 SELECT 虽不加锁，但其读取基于事务启动时的快照，后续 COMMIT 不影响该次查询结果
如果连接长期保持 autocommit=0 且无任何 DML，只是反复 SELECT，仍会维持一个空事务，可能拖慢 purge 线程清理旧版本

应用层连接池常忽略 autocommit 设置

Java 的 HikariCP、Python 的 pymysql 默认都继承 MySQL 服务端的 autocommit 值，但有些 ORM（如 Django）默认关闭自动提交，而 SQLAlchemy 默认开启。混用时极易出错。

Django 中 transaction.atomic() 会临时关闭 autocommit；若外层已关，嵌套事务实际是保存点（savepoint），不是新事务
Node.js 的 mysql2 在 connection.beginTransaction() 后自动设 autocommit=0，但连接复用时需注意是否残留未提交事务
最稳妥做法：在获取连接后第一件事就是检查并显式设置 SET autocommit = {0|1}，避免
依赖默认值