MySQL事务真正开始于第一条可执行DML语句执行时（autocommit=0下），而非BEGIN时刻；显式用BEGIN/START TRANSACTION则立即生效；纯SELECT不启动事务，但SELECT…FOR UPDATE或SELECT…INTO会触发。
事务到底从哪一刻真正开始？
MySQL事务的“开始”不是你敲下 BEGIN 的那一刻，而是**第一条可执行DML语句实际执行时**——前提是当前处于手动事务模式（autocommit = 0）。如果你用 SET @@autocommit = 0 关闭自动提交，之后哪怕只执行一条 SELECT（非锁读），事务也不会启动；但只要执行了 INSERT/UPDATE/DELETE 或带 FOR UPDATE/LOCK IN SHARE MODE 的 SELECT，InnoDB 就会立即隐式开启一个事务。
- 显式启动（推荐）：
BEGIN或START TRANSACTION后，事务立即生效，后续所有DML都在该事务中 - 隐式启动（易踩坑）：
SET @@autocommit = 0后未显式开启事务，却误以为“已进事务”，结果第一条DML才真正建事务，中间空档期的查询不受事务隔离保护 - 注意：纯
SELECT不触发事务启动，除非加锁；而SELECT ... INTO @var属于读写操作，会启动事务
事务内部SQL执行顺序 ≠ 书写顺序
很多人以为事务里SQL按代码顺序一条条原子执行，其实不然。事务内每条语句仍遵循MySQL标准执行流程：FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT，只是整个流程被包裹在事务上下文中，受ACID约束。
- 例如：事务中先
UPDATE再SELECT，看似顺序执行，但SELECT能看到前面UPDATE的未提交结果，是因为它们共享同一事务快照（取决于隔离级别） - 窗口函数（如
RANK() OVER(...)）在事务内也严格按执行顺序计算，但它的PARTITION BY和排序依据是当前事务已修改但未提交的数据 - 如果事务中混用DDL（如
ALTER TABLE），MySQL会**自动提交当前事务**再执行DDL，这是硬性规则，无法绕过
COMMIT/ROLLBACK 前，数据到底在哪？
事务未提交前，所有变更只存在于当前连接的内存缓冲区（InnoDB的redo log + buffer pool），其他会话不可见（按隔离级别略有差异），且断开连接会自动回滚——这点常被忽略，导致“我以为存了，其实没存”。
