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 中触发了什么资源申请、产生了哪些日志、是否触碰了隔离级别的快照边界。
