SQL事务的ACID特性由底层机制协同实现：原子性靠Undo Log回滚，一致性依赖其他三性与约束，隔离性通过锁和MVCC控制，持久性由Redo Log与WAL保障。
SQL数据库事务机制的核心，就是用ACID四个特性把一组操作“绑成一个整体”，让它在并发和故障面前依然可靠。这不是靠魔法，而是由日志、锁、版本控制等底层机制协同完成的。
原子性靠Undo Log实现回滚能力
事务中任何一条语句失败，整个事务都要撤回——这个“全有或全无”的保障，关键在于Undo Log。InnoDB在修改数据前，先把原值（包括主键、列旧值、事务ID）记入Undo Log。一旦需要回滚，就按日志反向执行：INSERT变DELETE，UPDATE恢复旧值，DELETE则重新插入。它不直接还原磁盘页，而是通过逻辑操作重建事务前状态。注意，Undo Log还被MVCC复用，所以不会在提交后立刻清除。
一致性是ACID的结果，不是单一技术能保证的
一致性指数据库始终处于合法状态，比如总金额不变、外键存在、CHECK约束不被破坏。但它本身没有专属实现机制，而是依赖其他三个特性的合力：原子性防止部分更新，隔离性避免并发干扰，持久性确保结果不丢失；再加上数据库层面的约束（主键、唯一、外键、CHECK）、触发器，以及应用层校验与业务逻辑。例如转账中余额不能为负，靠的是表定义里的CHECK(balance >= 0)，而不是事务自动赋予的。
隔离性靠锁与MVCC协同控制可见性
多个事务同时读写时，数据库必须决定谁能看到谁的修改。InnoDB主要用两种方式：
• 锁机制：对写操作加排他锁（X锁），读操作在需要时加共享锁（S锁）；间隙锁（Gap Lock）防止幻读；意向锁减少锁冲突检查开销。
• MVCC（多版本并发控制）：每行数据隐含创建版本号和删除版本号，事务开启时拿到一个快照Read View。读已提交每次SELECT都生成新快照；可重复读则整个事务复用初始快照，从而避免不可重复读。不同隔离级别本质就是快照策略+锁范围的组合。
持久性靠Redo Log和WAL原则落盘保障
事务一旦COMMIT，结果就必须永久保存。InnoDB采用预写式日志（WAL）：所有修改先写Redo Log（顺序追加、刷盘快），再异步更新Buffer Pool中的数据页。即使崩溃，重启后也能用Redo Log重放已提交但未写入磁盘的变更。关键点在于：Redo Log必须在事务提交前强制刷盘（innodb_flush_log_at_trx_commit=1），这是持久性的底线。Double Write Buffer进一步防止页写入中途损坏。
