mysql ACID特性是什么意思_mysql事务原理解析

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