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）
