事务到底从哪一刻真正开始？
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中触发了什么资源申请、产生了哪些日志、是否触碰了隔离级别的快照边界。
