ACID是MySQL事务的四大核心原则，由InnoDB等引擎通过Undo Log、MVCC、Redo Log等机制协同实现：原子性保障操作全成功或全回滚；一致性确保数据始终满足约束；隔离性避免并发干扰；持久性保证提交后数据不丢失。
MySQL 中的 ACID 特性是事务（Transaction）必须满足的四大核心原则，用于保障并发环境下的数据可靠性与一致性。它不是 MySQL 自身的“功能开关”，而是 InnoDB 等事务型存储引擎通过底层机制（如日志、锁、快照）实现的一组行为承诺。
原子性（Atomicity）：操作不可拆分
事务中的所有 SQL 操作被视为一个整体：要么全部成功提交（COMMIT），要么全部失败回滚（ROLLBACK），不允许部分生效。
- 典型场景：银行转账——A 账户扣款和 B 账户入账必须同时完成或同时撤销
- InnoDB 实现依赖 Undo Log：记录修改前的数据镜像，回滚时按日志逆向恢复
- 注意：只有 InnoDB、NDB 等支持事务的引擎才具备原子性；MyISAM 不支持
一致性（Consistency）：状态始终合法
事务执行前后，数据库必须从一个满足完整性约束的有效状态，转移到另一个同样有效的状态。
- 约束包括：主键唯一、外键关联、CHECK 条件、非空/类型校验等
- 一致性不是由单一机制保证，而是原子性、隔离性、持久性的共同结果
- 应用层也要参与：比如余额不能为负，需在 SQL 或业务逻辑中显式控制
隔离性（Isolation）：并发互不干扰
多个事务同时运行时，彼此的操作不应造成意外影响。MySQL 提供四种隔离级别，默认为 REPEATABLE READ。
- READ UNCOMMITTED：可能读到未提交数据（脏读）
- READ COMMITTED：避免脏读，但可能不可重复读
- REPEATABLE READ（默认）：避免脏读和不可重复读；InnoDB 用 MVCC + 间隙锁尽量规避幻读
- SERIALIZABLE：最严格，强制串行执行，开销最大
持久性（Durability）：提交即永久保存
一旦事务成功 COMMIT，其对数据的修改就应永久保留，即使发生断电、崩溃等故障也不丢失。
- InnoDB 采用 WAL（Write-Ahead Logging）机制：先写 Redo Log 到磁盘，再异步刷脏页
- 崩溃恢复时，MySQL 会重放 Redo Log 中已提交事务的修改
- Redo Log 是顺序写，性能高；而直接写数据文件是随机写，效率低
ACID 是一个协同体系：原子性防止“半途而废”，隔离性防止“互相踩脚”，持久性防止“功亏一篑”，最终共同服务于一致性的目标。
