ACID 是 MySQL 事务最核心的四个保障特性，不是功能开关，而是设计原则——它让数据库在出错、并发、断电等真实场景下，依然能守住数据的底线。
原子性：操作不能“只做一半”
事务里的所有 SQL 要么全成功，要么全回退，中间不许卡住。比如转账：从 A 扣 100 元 + 给 B 加 100 元，必须捆绑执行。哪怕第二步因网络中断失败，第一步也会被自动撤销，A 的钱不会凭空消失。
实现靠 undo log（回滚日志）：每改一条记录前，先记下怎么“反向还原”。一旦需要回滚，就按日志倒着擦除变更。
START TRANSACTION 开启事务 执行 UPDATE、INSERT 等语句 出错时用 ROLLBACK 撤销全部；没问题就 COMMIT 提交一致性：状态始终合法
这不是事务自己“保证”的结果，而是原子性、隔离性、持久性共同作用 + 数据库约束一起达成的目标。它体现为：事务前后，数据库必须满足预设规则。
例如：
余额不能为负（CHECK 约束） 订单必须关联真实用户（外键约束） 转账总额不变（业务逻辑隐含的一致性）如果某条 UPDATE 违反了 CHECK(amount > 0)，事务会直接报错并回滚，不让非法状态写入。
隔离性：并发时不互相干扰
多个事务同时跑，彼此该“看不见”对方未提交的修改。MySQL 默认用 可重复读（REPEATABLE READ） 级别，靠 MVCC（多版本并发控制）+ 间隙锁来实现。
不同级别解决的问题：
读未提交：可能读到别人还没 commit 的脏数据（脏读） 读已提交：避免脏读，但同一事务两次查可能结果不同（不可重复读） 可重复读：避免脏读和不可重复读，但可能看到新插入的行（幻读） 串行化：彻底排队执行，避免所有问题，但性能最低日常业务中，可重复读够用；强一致性要求（如金融核心账务）才考虑串行化或应用层加锁。
持久性：提交后就不会丢
COMMIT 一执行，数据就算断电、宕机、服务器重启，也必须还在磁盘上。InnoDB 靠 redo log（重做日志） 实现：先写日志再刷数据页，日志顺序写快，崩溃后靠它恢复未落盘的已提交变更。
注意：持久性针对的是已 COMMIT 的事务。没提交的，即使写进了缓冲池，崩溃后也会丢失。
不复杂，但容易忽略——ACID 不是独立存在的四个开关，而是一套协同机制。原子性兜底执行逻辑，隔离性管并发可见性，持久性保落地结果，三者合力，才撑得起“一致性”这个最终目标。
