MySQL事务是由InnoDB引擎实现的ACID特性保障机制，解决如银行转账中数据不一致问题：原子性靠Undo Log，隔离性靠锁+MVCC，持久性靠Redo Log，一致性由多机制协同达成。
MySQL 中的事务，就是一组数据库操作的“打包执行单元”——它要么全部成功，要么全部不执行，中间不能卡在半道上。这不是 MySQL 自己加的功能，而是由底层存储引擎（主要是 InnoDB）实现的机制，MyISAM 这类引擎就不支持事务。
事务解决什么实际问题？
最典型的例子是银行转账：
- 你账户减 100 元
- 对方账户加 100 元
- 网络断了、程序崩了、服务器宕机……只要其中一步失败，整个操作就得撤销
没有事务的话，可能出现“你扣了钱，对方没到账”的严重数据错乱。事务正是用来兜底的——靠的是 ACID 四大特性保障。
ACID 是怎么落地的？
每条特性背后都有具体的机制支撑，不是空口号：
- 原子性：靠 Undo Log 实现。事务开始前，把原始数据记下来；一旦要回滚，就用这些快照恢复回去
- 一致性：不是事务单独负责，而是靠原子性 + 隔离性 + 约束检查（如主键、外键、CHECK）共同达成的结果状态
- 隔离性：靠 锁 + MVCC（多版本并发控制） 实现。比如可重复读级别下，事务启动时会拍一个“数据快照”，后续读都基于这个快照，不受其他事务干扰
- 持久性：靠 Redo Log 实现。事务提交前，先把修改写进磁盘上的重做日志；即使断电，重启后也能按日志把已提交的操作补上
事务是怎么运行起来的？
InnoDB 使用 WAL（Write-Ahead Logging，预写式日志）机制：
- 所有变更先写 Redo Log（确保能持久），再更新内存中的数据页（Buffer Pool）
- Undo Log 同步生成，为回滚和 MVCC 提供历史版本
- 事务 ID 在第一次增删改时才分配，只读事务默认不分配
- 提交（
COMMIT）触发 Redo Log 刷盘；回滚（ROLLBACK）则用 Undo Log 撤销未提交的修改
几个关键注意点
- 事务必须搭配支持事务的引擎（如 InnoDB），建表时不指定引擎或用了 MyISAM，
BEGIN和COMMIT就形同虚设 - 自动提交（
autocommit=1）默认开启，单条 SQL 会自动成事务；想手动控制，得先SET autocommit = 0或显式用BEGIN - 长事务会持续占用 Undo Log 空间，还可能拖慢 purge 线程，影响性能和空间回收
- 隔离级别影响并发行为：MySQL 默认是 可重复读（Repeatable Read），不是读已提交（Read Committed）
