事务从 BEGIN
或 START TRANSACTION
开始，不是从第一条 SQL 开始
很多人误以为执行一条
UPDATE或
INSERT就自动进入事务，其实不然。MySQL 默认是自动提交模式（
autocommit=1），单条 DML 语句会立即落盘生效。事务真正启动的明确信号只有两个：
BEGIN和
START TRANSACTION—— 它们等价，且不带任何参数。执行完这个语句后，后续所有 DML（
INSERT/
UPDATE/
DELETE）才被纳入当前事务上下文。
常见错误现象：
- 执行了
UPDATE t1 SET x=1 WHERE id=1;后立刻执行
ROLLBACK;，发现没回滚 → 因为没先
BEGIN，这条 UPDATE 已自动提交。
- 在存储过程中漏写
START TRANSACTION，只靠逻辑判断是否执行
COMMIT，结果每条语句都独立提交。
BEGIN和
START TRANSACTION是显式开启事务的唯一可靠方式；
SET autocommit = 0虽然也能关闭自动提交，但属于会话级配置，易被覆盖或遗忘，不推荐用于业务逻辑控制 DDL（如
CREATE TABLE、
ALTER TABLE）在执行时会隐式触发
COMMIT，即使当前已有未提交事务，也会先提交再执行 DDL 某些客户端（如 MySQL Shell 的 JavaScript 模式）默认禁用
autocommit，容易造成本地行为和脚本上线后不一致，务必检查
SELECT @@autocommit;
COMMIT
和 ROLLBACK
的触发时机与副作用
COMMIT不仅提交当前事务修改，还会隐式开启下一个事务（在
autocommit=0模式下）；而
ROLLBACK清空当前事务所有变更，并让会话回到“无事务”状态（即下次 DML 又会自动提交，除非再次
BEGIN）。
关键细节：
-
COMMIT成功返回后，数据才对其他会话可见（取决于隔离级别，但至少已写入 redo log 并刷盘）；
-
ROLLBACK是即时的，不依赖磁盘 I/O，只撤销内存中的变更记录；
- 如果事务中执行了
SELECT ... FOR UPDATE或
LOCK IN SHARE MODE，
ROLLBACK也会释放这些行锁。 网络中断、客户端崩溃、连接超时等场景下，MySQL 服务端若未收到
COMMIT或
ROLLBACK，该事务会保持活跃状态，占用锁和 undo log 空间，直到超时（由
innodb_lock_wait_timeout和连接空闲时间共同决定） 不要依赖“连接断开即自动回滚”——虽然大多数情况下如此，但极端条件下（如主从切换期间连接残留）可能留下长事务，需监控
INFORMATION_SCHEMA.INNODB_TRX
隐式提交场景：哪些操作会偷偷 COMMIT
当前事务
MySQL 中不少语句会强制结束当前事务，不管有没有显式
COMMIT。这类“隐式提交”最容易让人踩坑，尤其在拼接动态 SQL 或混用 DDL/DML 时。
典型触发语句包括：
- 所有 DDL：
CREATE、
DROP、
ALTER、
TRUNCATE、
RENAME TABLE
- 管理类命令：
ANALYZE TABLE、
OPTIMIZE TABLE、
REPAIR TABLE
- 复制相关：
START SLAVE、
STOP SLAVE、
RESET SLAVE
- 全局操作：
SET PASSWORD、
GRANT、
REVOKE执行
CREATE TEMPORARY TABLE不会隐式提交，这是少数例外 在事务中执行
INSERT INTO t SELECT ... FROM other_table是安全的；但如果
other_table是视图且底层含 DDL，仍可能触发隐式提交（取决于视图定义） 使用
mysqldump --single-transaction时，它靠的是
START TRANSACTION WITH CONSISTENT SNAPSHOT，该语法本身不会导致后续 DDL 隐式提交，但 dump 过程中若你手动执行 DDL，就会中断快照一致性
事务实际生效的关键依赖：隔离级别 + 存储引擎 + binlog 格式
事务“生效”不只是数据改没改，还包括其他会话能否看到、主从是否一致、崩溃后能否恢复。这三者必须协同：
InnoDB 是唯一完整支持 ACID 的引擎；MyISAM 完全不支持事务，BEGIN对它无效 隔离级别影响“生效”的语义：
READ COMMITTED下，事务内多次
SELECT可能读到不同结果；
REPEATABLE READ（默认）则保证一致性读，但幻读仍可能通过
INSERT触发
binlog_format=STATEMENT时，事务内含不确定函数（如
NOW()、
UUID()）可能导致主从不一致；
ROW格式可避免，但日志体积更大 如果启用了
innodb_flush_log_at_trx_commit=2，
COMMIT后 redo log 只写入 OS cache，不强制刷盘——此时断电可能丢失最近一个事务，但不影响事务的原子性语义（只是持久性降级）
最常被忽略的一点：事务是否“真正安全”，不取决于你写了几个
COMMIT，而取决于
innodb_flush_log_at_trx_commit、
sync_binlog和磁盘本身的 write cache 设置是否匹配你的可靠性要求。
