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 就是补这个缺口的日志。
容易被忽略的持久性断层
即使 innodb_flush_log_at_trx_commit = 1，仍有几个现实断层会让“已提交”变“疑似丢失”：
- 文件系统缓存：某些挂载参数（如
mount -o barrier=0）可能绕过磁盘写屏障，导致fsync返回成功但实际未落物理扇区 - 磁盘/RAID 缓存：若磁盘开启 write-back 缓存且无电池/电容保护，
fsync成功后断电仍可能丢日志 - 云数据库（如 RDS）：底层存储可能是分布式块设备，
fsync行为受厂商实现影响，文档通常不会明说是否强刷物理介质
所以生产环境若要求强持久性，除了配置 =1，还要确认存储栈是否支持真正的 force unit access (FUA) 或等效机制 —— 这一点，多数业务根本没验证过。
