事务真正开始于第一条dml执行时，而非begin；此时才分配事务id、生成undo日志并进入活跃状态。
事务真正开始的那一刻：不是BEGIN，而是第一条DML执行时
很多人误以为 START TRANSACTION 或 BEGIN 就是事务“启动”的瞬间，其实不然。MySQL 的事务在逻辑上从第一条 DML（INSERT/UPDATE/DELETE）语句执行时才真正“激活”——此前即使已显式开启事务，也尚未产生任何 undo log 或事务上下文。也就是说：
• START TRANSACTION 只是标记一个事务边界起点，不触发日志写入
• 第一条 DML 才真正分配事务 ID、生成 undo 日志、进入活跃状态
• 若开启事务后只执行 SELECT，仍处于空闲事务（idle transaction），不占用锁资源也不影响 MVCC 版本链
自动提交模式下，每条 DML 都是独立事务
默认 @@autocommit = 1 时，MySQL 对每条 DML 隐式执行：
• START TRANSACTION
• 执行该语句
• 立即 COMMIT
这意味着你根本无法回滚单条语句——它自己就是完整事务。常见误解是“我写了 UPDATE 没 COMMIT，数据没变”，但实际只要没报错，它已经提交了。
• 查看当前模式：SELECT @@autocommit;
• 关闭自动提交：SET autocommit = 0;（注意：这是会话级设置，新连接仍为 1）
• 关键点：关闭后，必须显式 COMMIT 或 ROLLBACK，否则事务长期挂起，可能阻塞 purge 线程、撑高 undo 表空间
事务生命周期与执行流程的关键节点
MySQL 执行一条带事务的 DML，背后经历的典型流程如下：
• 连接器鉴权 → 查询缓存跳过（DML 不走缓存）→ 分析器语法解析 → 优化器生成执行计划 → 执行器调用存储引擎接口
• 引擎层（InnoDB）介入后：
– 检查行锁/间隙锁是否冲突（隔离级别决定）
– 读取聚簇索引页到 buffer pool
– 写入 undo log（用于回滚和 MVCC）
– 修改内存中数据页（脏页）
– 记录 redo log（prepare 阶段写入，commit 时刷盘或组提交）
• 最终落盘靠的是 COMMIT 触发的 redo log fsync，而非 SQL 执行完成那一刻
容易被忽略的坑：事务未结束 ≠ 数据未修改
事务仍在运行中时，其他事务能否看到你的修改？答案取决于隔离级别，但更隐蔽的问题是：
• 即使你还没 COMMIT，当前会话内所有后续 SELECT 都能立即看到自己刚做的 DML（这叫“读己之所写”，read your own writes），这是事务可见性的基本保障，不是 bug
• 但如果你在事务中执行了 SELECT ... FOR UPDATE，又没 COMMIT，锁会一直持有，可能导致其他会话死锁或长时间等待
• 更危险的是：忘记 COMMIT 后直接断开连接——MySQL 默认会自动 ROLLBACK，但某些客户端（如部分 JDBC 驱动配置 autoReconnect=true）可能重连后继续旧事务，造成意外交互
