mysql中基于事务的持久性与一致性保证_技术教程

MySQL事务的持久性靠redo log刷盘机制和innodb_flush_log_at_trx_commit参数协同实现：=1时每次COMMIT强制fsync，=0时每秒刷一次，=2时仅写入OS缓存；核心是redo log落盘而非数据页刷盘。

事务的持久性在 MySQL 中靠什么实现

MySQL 的持久性（Durability）不是靠“写完磁盘就完事”来保证的，而是依赖 redo log 的刷盘机制和 innodb_flush_log_at_trx_commit 参数协同控制。它解决的是“事务提交后崩溃，数据会不会丢”的问题。

innodb_flush_log_at_trx_commit = 1：每次 COMMIT 都强制将 redo log buffer 刷入磁盘（fsync），最安全，但有 I/O 开销
= 0：每秒刷一次日志，事务提交不刷盘 —— 崩溃可能丢失最多 1 秒事务
= 2：事务提交时只写入 OS 缓存（write），不 fsync —— 崩溃但 OS 没崩则不丢；OS 崩溃仍可能丢

注意：sync_binlog 也影响主从一致性，但持久性核心看 redo log 刷盘行为，binlog 是复制与恢复辅助，不直接提供单机持久性保障。

一致性（Consistency）不是 MySQL 自动兜底的

MySQL 的事务机制本身不校验业务逻辑是否一致，它只保证 ACID 中的 A（原子性）、I（隔离性）、D（持久性）。所谓“一致性”，是开发者用约束、触发器、应用层逻辑共同维护的结果。

PRIMARY KEY、UNIQUE、FOREIGN KEY 约束能防止明显的数据矛盾，但无法覆盖语义级规则（比如“余额不能为负”需靠 CHECK 或应用判断）
CHECK 约束在 MySQL 8.0.16+ 才真正生效；低版本中定义了也无效，容易误以为被校验了
跨表逻辑（如订单创建时扣库存）必须用事务包裹多个 DML，并确保所有操作成功或全部回滚 —— 否则即使单条 SQL 符合约束，整体状态仍可能不一致

一个典型陷阱：UPDATE account SET balance = balance - 100 WHERE id = 1 AND balance >= 100 看似防负数，但如果并发执行且没加锁，仍可能因检查与更新非原子而超扣（即“检查-修改”竞态）。这时需要 SELECT ... FOR UPDATE 或应用层重试。

事务提交瞬间到底发生了什么

理解这一步，才能明白为什么持久性和一致性不是“一提交就万事大吉”。

1. 事务内所有变更先写入 InnoDB 的内存页（buffer pool）和 redo log buffer  
2. 执行 COMMIT 时：  
   - 若 innodb_flush_log_at_trx_commit = 1：redo log buffer 调用 fsync 写入磁盘的 ib_logfile*  
   - 同时，事务的 commit LSN（日志序列号）被标记为“已提交”  
3. 此时事务对其他事务可见（取决于隔离级别），且即使实例崩溃，重启时 InnoDB 会用 redo log 恢复该事务的修改

关键点：数据页（buffer pool）本身此时未必刷盘（dirty page 可延后刷），但 redo log 已落盘 → 这就是持久性的来源。如果只依赖数据页刷盘，崩溃时未刷的页就丢了，redo log 就是补这个缺口的日志。