MySQL事务四大特性ACID是保障数据可靠的四道防线：原子性用Undo Log确保操作全成功或全回滚；一致性由约束、触发器及ACID其他特性协同实现；隔离性通过MVCC和锁机制支持不同隔离级别；持久性靠Redo Log刷盘与崩溃恢复保证提交即永久。
MySQL事务的四大特性ACID，不是抽象概念，而是数据库在真实场景中保障数据可靠的四道防线。理解它们的关键，是把每个特性对应到具体问题：比如转账失败时钱没丢、并发下单不超卖、系统断电后数据不乱——这些都靠ACID一层层兜底。
原子性：操作不能“做一半”
事务是一个不可拆分的最小执行单元。比如从A账户扣100元、向B账户加100元，这两步必须同时成功或同时撤销。哪怕执行到第二步时数据库崩溃，InnoDB也会用Undo Log自动回滚第一步，让整个事务像没发生过一样。
- 不是靠程序try-catch控制，而是由存储引擎（InnoDB）底层日志机制保证
- 即使客户端收到“执行成功”响应前发生宕机，只要事务没提交，就不会留下中间状态
- 手动触发回滚（ROLLBACK）或异常中断，都会激活Undo Log恢复原始数据
一致性：结果必须“合法且合理”
一致性不是数据库单独实现的特性，而是原子性、隔离性、持久性共同作用的结果。它体现为：事务开始前和结束后，数据库始终满足所有预设规则——比如主键不重复、外键有对应记录、金额总和不变。
- 转账前后，A+B账户余额总和必须恒定（业务逻辑约束）
- 插入订单时，必须关联存在的用户ID（外键约束）
- 触发器、CHECK约束、唯一索引等，都是支撑一致性的具体手段
隔离性：并发操作互不“串场”
多个事务同时运行时，每个事务都应像在独立环境中执行。MySQL通过MVCC + 锁机制实现不同隔离级别，默认是可重复读（REPEATABLE READ）。
- 读已提交（READ COMMITTED）：能看到其他事务已提交的修改
- 可重复读（REPEATABLE READ）：同一事务内多次查询结果一致，避免不可重复读
- 幻读问题通过间隙锁（Gap Lock）或临键锁（Next-Key Lock）缓解
- 隔离级别越高，性能开销越大，需按业务权衡选择
持久性：提交之后“永不丢失”
一旦事务提交（COMMIT），数据修改就必须永久保存，即使随后发生断电、进程崩溃或磁盘故障。MySQL靠Redo Log确保这一点：修改先写入日志并刷盘，再更新内存；崩溃恢复时，用Redo Log重放未落盘的数据变更。
- Redo Log是物理日志，记录“在某个数据页做了什么修改”
- 配合双写缓冲（Doublewrite Buffer）防止页写入半截损坏
- Binlog用于主从复制和逻辑备份，不直接参与持久性保障
