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}，避免依赖默认值
事务边界的模糊性最容易被低估——它不只是语法开关，还牵扯锁生命周期、MVCC 快照起点、binlog 写入时机、主从延迟表现。尤其在微服务间共享数据库连接池时，一个没
COMMIT的事务可能卡住下游十几个请求。
