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不小心触发了隐式提交。这些细节不摸透，调参、压测、排障全在猜。
