事务从 BEGIN 或 START TRANSACTION 显式开始，非首条 SQL；MySQL 默认 autocommit=1，单条 DML 立即提交；DDL 等语句会隐式提交当前事务；COMMIT 后隐式开启新事务，ROLLBACK 回到无事务状态。
事务从 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 设置是否匹配你的可靠性要求。
