MySQL的ACID事务特性由InnoDB引擎通过undo log、约束校验、MVCC+行锁、redo log分别实现原子性、一致性、隔离性、持久性，保障数据安全可靠。
MySQL的ACID事务特性是保障数据操作安全、可靠的核心机制。它不是抽象概念，而是InnoDB存储引擎在底层通过日志、锁和版本控制等技术实实在在实现的一套规则。理解ACID，关键在于知道每个特性“管什么”以及“怎么管”，而不是死记定义。
原子性：操作必须全成或全败
原子性保证一个事务里的所有SQL语句像一个整体——不能只执行一半。比如转账时扣A的钱和加B的钱，必须同时成功或同时撤销。
- InnoDB靠undo log（回滚日志）实现：每执行一条修改语句，就记录对应的“反向操作”（如UPDATE会存原值），一旦出错或执行ROLLBACK，就用这些日志把已做的修改全部撤回。
- 注意：只有InnoDB等支持事务的引擎才具备原子性；MyISAM不支持事务，也就没有原子性。
一致性：数据始终合法且符合业务逻辑
一致性不是数据库单独实现的特性，而是原子性、隔离性、持久性共同作用的结果，再加上约束校验的配合。
- 它要求事务前后，数据库必须处于合法状态：比如主键不能重复、外键必须存在、余额不能为负、转账前后总金额不变等。
- InnoDB会在执行过程中实时检查NOT NULL、UNIQUE、FOREIGN KEY等约束；违反即中断并回滚。业务层也需配合校验（如判断余额是否足够扣款）。
隔离性：并发事务互不干扰
多个事务同时运行时，每个事务都应像在独占数据库一样工作。隔离性解决的是并发场景下的脏读、不可重复读、幻读问题。
- InnoDB默认使用可重复读（REPEATABLE READ）隔离级别，主要靠MVCC（多版本并发控制） + 行锁实现。
- 不同隔离级别对应不同并发行为：读未提交能看到别人未提交的数据；读已提交每次SELECT都看到最新已提交结果；可重复读保证同一事务中多次读取结果一致；串行化最安全但性能最低。
持久性：提交后的数据永不丢失
一旦COMMIT成功，数据就必须永久保存，即使系统突然断电或崩溃也不能丢。
- InnoDB通过redo log（重做日志）实现：事务提交前，先将修改内容写入redo log并刷盘；即使数据页还没写进磁盘，崩溃恢复时也能根据redo log重新应用变更。
- 注意：redo log是物理日志，记录“在哪个数据页做了什么修改”，不是SQL语句本身。
