MySQL 默认的 autocommit 行为到底开没开？
绝大多数 MySQL 客户端（包括
mysql命令行、Navicat、DBeaver）连接成功后，
autocommit默认是开启的。你可以用
SELECT @@autocommit;确认——返回
1就表示自动提交已启用。
这意味着：每条
INSERT、
UPDATE、
DELETE语句执行完就立刻持久化，不依赖
COMMIT，也无法用
ROLLBACK撤销。 只有显式执行
START TRANSACTION或
BEGIN后，才进入事务上下文，
autocommit临时失效
SET autocommit = 0;可全局关闭当前会话的自动提交，但不推荐长期使用——容易忘记恢复，导致后续所有 DML 都滞留在未提交状态 DDL 语句（如
CREATE TABLE、
ALTER TABLE）无论
autocommit如何，都会隐式触发
COMMIT
InnoDB 和 MyISAM 对事务的支持差异
存储引擎决定你能不能真正用上事务。
InnoDB支持完整的 ACID 事务、行级锁和外键；
MyISAM完全不支持事务，也没有
ROLLBACK能力——哪怕你写了
START TRANSACTION，执行
ROLLBACK也什么都不会发生。
检查表引擎用：
SHOW CREATE TABLE table_name;或
SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'db_name' AND TABLE_NAME = 'table_name';创建表时没指定
ENGINE=InnoDB，MySQL 8.0+ 默认用
InnoDB，但老版本或某些配置下可能 fallback 到
MyISAM
ALTER TABLE t ENGINE=InnoDB;可在线转换（MySQL 5.6+），但大表会锁写，且需足够磁盘空间做重建 如果误用了
MyISAM表却写了事务逻辑，
ROLLBACK不报错但也不起作用——这是最隐蔽的“事务失效”场景
事务中混合 DML 与 DDL 的陷阱
在
START TRANSACTION内执行 DDL（比如
ALTER TABLE），MySQL 会**立即隐式提交当前事务**，然后执行 DDL，再开启新事务（如果后续还有 DML）。
这意味着：
DDL 前的 DML 已经不可回滚 DDL 后的 DML 属于另一个事务，ROLLBACK只能撤掉它，不影响前面已提交的部分 这个行为在所有存储引擎中一致，和
autocommit设置无关
START TRANSACTION;
INSERT INTO users (name) VALUES ('alice');
ALTER TABLE users ADD COLUMN age INT; -- 此刻 INSERT 已提交
INSERT INTO users (name) VALUES ('bob'); -- 这条可被 ROLLBACK
ROLLBACK; -- 只撤销第二条 INSERT，'alice' 仍存在应用层连接池里 autocommit 的常见误设
Java 的 HikariCP、Python 的 PyMySQL、Node.js 的 mysql2 等客户端库，通常默认将连接的
autocommit设为
true。但有些框架（如旧版 Django）或自定义封装会改成
false，导致连接复用时事务状态“污染”。
典型表现：A 请求手动
begin+
commit，B 请求复用同一连接但没显式开启事务，结果 B 的单条
UPDATE却被卡在未提交状态，直到连接关闭或超时回滚。 最佳实践：不在连接池层面统一关
autocommit，而是由业务逻辑按需控制——用
connection.begin()/
start_transaction()显式开启 务必确认 ORM 或驱动是否在
execute()前自动加了
START TRANSACTION（例如 SQLAlchemy 的
connection.execute(...)默认不启事务，但
session.add()会绑定到 session 级事务） 监控
information_schema.INNODB_TRX表，查长时间未提交的
trx_state = 'RUNNING'事务，往往是连接池 + autocommit 配置混乱的直接证据
事务真正的复杂点不在语法，而在跨语句、跨连接、跨引擎的状态一致性。尤其当 DDL 插入事务中间，或连接被复用却未重置 autocommit 时，问题往往延迟暴露，排查成本远高于预防。
