事务的持久性在 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)或等效机制 —— 这一点，多数业务根本没验证过。
