事务未提交时，innodb只修改内存中的数据页（生成脏页），不写入磁盘，以保障原子性并提升性能；redo log也暂存于buffer中，未持久化到ib_logfile，直至commit触发fsync。
事务未提交时，InnoDB只改内存里的数据页
因为InnoDB默认采用“延迟写”策略：所有DML操作（INSERT、UPDATE、DELETE）都先作用于Buffer Pool中的数据页，生成脏页，但不会立刻刷盘。这是性能和一致性的双重选择——直接写磁盘太慢，且没提交就落盘会破坏原子性。
常见错误现象：SELECT在另一个连接里查不到未提交的修改；SHOW PROCESSLIST看到线程卡在Waiting for table metadata lock，其实是因为长事务没提交，一直占着MDL锁。
- 事务开启后，所有变更都在Buffer Pool中完成，对应的数据页变成“脏页”
- Undo Log同步生成，用于回滚；Redo Log Buffer也记录物理修改动作，但此时还没刷到磁盘的
ib_logfile* - 其他事务读取时，通过MVCC+Read View机制，自动过滤掉未提交版本，所以看不到这些修改
Redo Log不落盘，事务就不算真正持久
事务提交（COMMIT）那一刻的关键动作，不是把数据页写磁盘，而是把Redo Log Buffer里的日志强制刷到磁盘文件（ib_logfile0等）。只要这一步成功，哪怕随后服务器宕机，重启后也能靠重放Redo Log恢复已提交的修改。
为什么不能跳过这步？因为数据页刷盘（checkpoint）是异步、批量、延迟的，可能几分钟后才发生。如果只靠刷数据页来保证持久性，中间窗口期一旦崩溃，已提交的数据就丢了。
-
innodb_flush_log_at_trx_commit = 1（默认值）：每次COMMIT都触发fsync，最安全 -
= 0：日志只写入OS缓存，每秒刷一次，崩溃可能丢1秒事务 -
= 2：日志写入OS缓存，但COMMIT时仅fdatasync，不fsync，安全性介于两者之间
未提交事务长期挂起，会引发哪些实际问题？
它不改磁盘，但会持续占用内存、锁和系统资源。最典型的线上故障就是ALTER TABLE被卡住，报错Waiting for table metadata lock——根源往往是一个忘了COMMIT的SELECT或UPDATE事务，持有了MDL读锁，阻塞了DDL所需的MDL写锁。
排查时别只看SHOW PROCESSLIST，重点查INNODB_TRX表：
-
TRX_STARTED时间异常久（比如几小时），说明事务早开始了但没结束 -
TRX_QUERY为NULL，代表事务已启动、尚未执行任何语句（常见于应用层开了事务但逻辑卡住） -
TRX_ROWS_LOCKED或TRX_LOCK_STRUCTS值很大，说明锁持有范围广，影响面大
手动提交不是唯一出口，但autocommit=1才是默认现实
很多初学者以为“没写COMMIT就等于没提交”，却忽略了MySQL默认autocommit = 1。这意味着每条独立的INSERT、UPDATE、DELETE语句本身就是个事务，执行完就自动提交了。只有显式执行SET autocommit = 0或START TRANSACTION后，后续语句才进入手动控制模式。
所以“事务未提交”的典型场景，其实是开发误关了autocommit，又忘记加COMMIT，或者框架事务管理配置出错（如Spring的@Transactional没生效、异常未抛出导致没触发回滚/提交）。
真正容易被忽略的是：事务未提交本身不写磁盘，但它拖得越久，Buffer Pool中脏页越多、Undo Log链越长、锁持有越久——这些都会悄悄拖慢整个实例，而错误日志里往往不报错，只在监控里看到Innodb_row_lock_time_avg缓慢爬升或Threads_running持续偏高。
