MySQL的ACID是InnoDB通过undo log、redo log、锁和MVCC实现的硬性承诺：原子性靠undo log回滚，隔离性由隔离级别+行锁+MVCC保障，持久性依赖redo log+doublewrite，一致性是前三者共同作用的结果。
MySQL 的 ACID 特性不是抽象概念，而是 InnoDB 存储引擎用 undo log、redo log、锁和 MVCC 共同兑现的硬性承诺——只要用对引擎、关掉 autocommit、正确配隔离级别，它就真能保证事务不丢、不乱、不脏、不幻。
原子性靠 undo log 回滚，不是靠“语句重试”
很多人误以为原子性是数据库自动重试失败语句，其实完全相反：一旦某条 UPDATE 报错（比如违反唯一键），InnoDB 会立即用 undo log 把前面已执行成功的操作（如前一条 INSERT）彻底抹掉，回到事务开始前的镜像状态。
-
START TRANSACTION后每条修改语句，都会在undo log中记下“怎么反向恢复”的指令（比如删除记录时记下插入前的完整行） - 显式
ROLLBACK或隐式崩溃回滚，都依赖这些日志，而不是靠重新执行 SQL - 如果事务中混入了
DROP TABLE这类 DDL，会强制COMMIT当前事务——undo log对 DDL 不生效，这是高频翻车点
隔离性由隔离级别 + 行锁 + MVCC 共同决定
InnoDB 默认的 REPEATABLE READ 看似“读一致性最强”，但实际行为和直觉有偏差：它用快照读（MVCC）避免不可重复读，却仍可能遇到幻读（新插入行）；而真正解决幻读要靠 SELECT ... FOR UPDATE 触发间隙锁。
-
READ COMMITTED：每次SELECT都读最新已提交版本，可能两次查询结果不同（不可重复读） -
REPEATABLE READ：第一次SELECT后生成事务级快照，后续读都基于它，但新插入行若没被锁住，就会“凭空出现”（幻读） - 想彻底禁幻读？必须用
SELECT * FROM t WHERE id > 100 FOR UPDATE—— 这会锁住id=100后的间隙，阻止其他事务插入
持久性不等于“写完磁盘”，而是 redo log + doublewrite 保障
你执行 COMMIT 成功，并不表示数据已落盘。InnoDB 先把变更写进内存中的 Buffer Pool，同时追加到 redo log 文件（顺序 I/O，极快），再标记事务为“已提交”。崩溃重启时，用 redo log 重放未刷盘的变更。
-
innodb_flush_log_at_trx_commit = 1（默认）：每次COMMIT都强制刷redo log到磁盘，最安全但稍慢 -
= 0：每秒刷一次，崩溃可能丢一秒事务；= 2：只写 OS 缓存，不 fsync，依赖系统稳定性 - 别忽略
doublewrite buffer：它把页先写入共享表空间的连续区域，防止部分写（partial page write）导致页损坏
一致性是 ACID 的结果，不是独立机制
MySQL 不提供叫“consistency check”的功能。所谓一致性，是原子性（不半途而废）、隔离性（不读脏/幻数据）、持久性（不丢已提交）三者叠加后，让约束（主键、外键、CHECK）和业务逻辑（如转账余额守恒）自然成立的结果。
- 如果你的事务里没做校验，比如转账没查余额就扣款，ACID 也救不了逻辑错误
- 外键约束只在 InnoDB 生效，MyISAM 完全无视——
SHOW ENGINES看清楚当前表引擎 - 触发器和存储过程里的异常不会自动触发事务回滚，必须显式写
DECLARE EXIT HANDLER捕获并ROLLBACK
真正难的从来不是记住 ACID 四个字母，而是理解 undo log 和 redo log 在哪一刻写、写什么、被谁读；是分清 MVCC 快照读和加锁读的区别；是在 autocommit=0 下，一个 SELECT 不小心触发了隐式提交。这些细节不摸透，调参、压测、排障全在猜。
