mysql事务什么时候开始_mysql事务执行顺序解析

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），其他会话不可见（按隔离级别略有差异），且断开连接会自动回滚——这点常被忽略，导致“我以为存了，其实没存”。

• COMMIT 不等于“写入磁盘”：它只是将redo log刷盘并标记事务为已提交，数据页可能仍在buffer pool中异步刷盘
• ROLLBACK 是回退到事务起点，靠undo log实现；若事务过大，undo log可能撑爆表空间，引发 Error 1568 (HY000): Unable to open undo tablespace
• 长事务（运行超60秒）会阻塞purge线程，拖慢整个实例性能；可用 SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), TRX_STARTED)) > 60 定期巡检

为什么有时 COMMIT 没反应、有时又卡住？

表面是提交慢，本质是锁等待或刷盘压力。常见真实原因有：

• 被其他事务持有了行锁或间隙锁，比如你在更新某条记录，而另一事务正对该记录加 SELECT ... FOR UPDATE 并未提交
• redo log 写满，触发 checkpoint，强制刷脏页，此时 COMMIT 会等刷盘完成
• 设置了 innodb_flush_log_at_trx_commit = 1（默认安全模式），每次 COMMIT 都要同步刷redo log到磁盘，遇到磁盘I/O瓶颈就明显卡顿
• 事务中包含大字段（TEXT/BLOB）或大量更新，undo log膨胀，回滚段争用加剧

事务的边界比看起来更“软”：它既受SQL逻辑顺序影响，又被存储引擎底层机制（锁、日志、缓冲）动态调节。别只盯着BEGIN和COMMIT，真正决定事务行为的是你写的每一条语句在InnoDB中触发了什么资源申请、产生了哪些日志、是否触碰了隔离级别的快照边界。