ACID 是 InnoDB 用 undo log、redo log、锁机制和 doublewrite buffer 等组件实现的：原子性靠 undo log 回滚链，隔离性由 MVCC 加行锁保障，持久性依赖 redo log 两阶段提交，一致性是其他三者与约束共同作用的结果。
MySQL 事务的特性就是 ACID —— 它不是抽象概念，而是 InnoDB 存储引擎用 undo log、redo log、 锁机制 和 doublewrite buffer 等实实在在的组件硬扛出来的。你写的每一条 START TRANSACTION，背后都在触发这些机制协同工作。
原子性靠 undo log 回滚链实现
事务中任意一步失败（比如 UPDATE 违反唯一约束），InnoDB 不会只“撤掉这一步”，而是根据该事务的 undo log 记录，把所有已做的变更逆向还原——就像倒带一样回到事务开始前的状态。
-
undo log是在事务执行过程中实时写入的，即使事务中途崩溃，重启后也能靠它回滚 - 大事务（比如批量更新百万行）会产生大量
undo log，可能占满undo tablespace，导致ERROR 1205 (HY000): Deadlock found when trying to get lock或Lock wait timeout exceeded -
ROLLBACK不是“删除日志”，而是用日志重放反向操作；所以回滚大事务可能比提交还慢，且引发高 I/O
隔离性由 MVCC + 行锁共同控制
InnoDB 默认隔离级别是 REPEATABLE READ，它不靠锁住整张表来实现，而是结合多版本并发控制（MVCC）和 next-key lock 来平衡安全与性能。
- 同一事务内多次
SELECT能看到相同快照，靠的是事务启动时分配的read view，而不是加读锁 - 但
UPDATE/DELETE仍会加行锁或间隙锁，避免幻读；如果只靠 MVCC，INSERT就可能绕过检查造成数据不一致 - 切忌在事务里混用
SELECT …… FOR UPDATE和普通SELECT：前者会升级为当前读，破坏一致性快照，容易引发死锁
持久性依赖 redo log 的两阶段提交
你执行 COMMIT 后立刻能查到新数据，并不意味着数据已刷进表空间文件——真正落盘靠的是 redo log 的 prepare → commit 两阶段写入。
- 只要
redo log的commit记录写成功（默认innodb_flush_log_at_trx_commit = 1），即使 MySQL 崩溃，重启时也能从日志恢复已提交事务 - 设成
0或2会提升写入性能，但崩溃可能丢失最多 1 秒事务——线上交易系统严禁这么配 -
redo log空间有限（默认 48MB），写满会阻塞事务，监控Innodb_os_log_pending_fsyncs和Innodb_log_waits很关键
一致性是 ACID 的结果，不是独立机制
Consistency 不像其他三项有专属日志或锁结构，它是原子性、隔离性、持久性 + 业务逻辑 + 数据库约束（主键、外键、CHECK）共同达成的效果。
- 转账例子中“总额不变”不是数据库自动保证的，而是靠你在事务里写对了两条
UPDATE，再配合原子性和隔离性不被干扰 - InnoDB 会强制校验外键、唯一索引等约束，一旦违反就直接报错并触发回滚——这是它保障一致性最实在的动作
- 如果你在事务里绕过约束（比如用
INSERT IGNORE忽略重复键），或在应用层做计算（如余额 = SUM(transactions)），那数据库就管不了“逻辑一致性”了
真正难的从来不是记住 ACID 四个字母，而是理解：每个 COMMIT 都在调用磁盘、内存、锁管理器三套系统协同工作；而任何一个环节配置不当（比如关了 sync_binlog 又没开半同步复制），都可能让“已提交”的事务在主从切换后人间蒸发。
