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