当MySQL崩溃并重启后，有时已提交的事务数据可能会丢失。这可能与MySQL的redo log相关，特别是参数`innodb_flush_log_at_trx_commit`的设置。该参数控制事务提交时刷redo log的策略，其值为0、1或2分别对应最佳性能、强一致性和折衷策略。为确保事务ACID特性，通常推荐设置为2，以平衡性能和数据安全性。若发生数据丢失，建议检查此配置。
有个水友提问：
沈老师，我们有一次MySQL崩溃，重启后发现有些已经提交的事务对数据的修改丢失了，不是说事务能保证ACID特性么，想问下什么情况下可能导致“事务已经提交，数据却丢失”呢？
这个问题有点复杂，得先从redo log说起。
为什么要有redo log？
事务提交后，必须将事务对数据页的修改刷(fsync)到磁盘上，才能保证事务的ACID特性。
这个刷盘，是一个随机写，随机写性能较低，如果每次事务提交都刷盘，会极大影响数据库的性能。
随机写性能差，有什么优化方法呢？
架构设计中有两个常见的优化方法：
（1）先写日志(write log first)，将随机写优化为顺序写；
（2）将每次写优化为批量写；
这两个优化，数据库都用上了。
先说第一个优化，将对数据的修改先顺序写到日志里，这个日志就是redo log。
假如某一时刻，数据库崩溃，还没来得及将数据页刷盘，数据库重启时，会重做redo log里的内容，以保证已提交事务对数据的影响被刷到磁盘上。
一句话，redo log是为了保证已提交事务的ACID特性，同时能够提高数据库性能的技术。
既然redo log能保证事务的ACID特性，那为什么还会出现，水友提问中出现的“数据库崩溃，丢数据”的问题呢？一起看下redo log的实现细节。
redo log的三层架构？
画了一个丑图，简单说明下redo log的三层架构
最低0.47元/天 解锁文章
扫一扫
261
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
