MySQL持久化和回滚该怎么领会
发布时间：2022-06-16 18:12:16 所属栏目：MySql教程 来源：互联网
导读：这篇文章跟大家分析一下MySQL持久化和回滚该怎么理解。内容详细易懂，对MySQL持久化和回滚该怎么理解感兴趣的朋友可以跟着小编的思路慢慢深入来阅读一下，希望阅读后能够对大家有所帮助。下面跟着小编一起深入学习MySQL持久化和回滚该怎么理解的知识吧。
|
这篇文章跟大家分析一下“MySQL持久化和回滚该怎么理解”。内容详细易懂，对“MySQL持久化和回滚该怎么理解”感兴趣的朋友可以跟着小编的思路慢慢深入来阅读一下，希望阅读后能够对大家有所帮助。下面跟着小编一起深入学习“MySQL持久化和回滚该怎么理解”的知识吧。 它的流程大概是这样的： 先判断user_id这条数据所在的页是否在内存里，如果不在的话，先从数据库读取到，然后加载到内存中 修改内存中的age为11 写入redo log，并且redo log处于prepare状态 写入binlog 提交事务，redo log变成commit状态 MySQL持久化和回滚该怎么理解 这里面有几个关键的点：redo log是什么？为什么需要redo log？prepare状态的redo log是什么？redo log和binlog是否可以只选其一...?带着这一系列的问题，我们来揭开redo log的面纱。 为什么要先更新内存数据，不直接更新磁盘数据？ 我们为什么不每次更新数据的时候，直接更新对应的磁盘数据？首先我们知道磁盘IO是缓慢的，内存是快速的，两者的速度不是一个量级的，那么针对缓慢的磁盘IO，出现了索引，通过索引哪怕数据成百上千万我们依然可以在磁盘上很快速的找我们的数据，这就是索引的作用。但是索引也需要维护，并不是一成不变的，当我们插入一条新数据A的时候，由于这条数据要插入在已存在的数据B之后，那么就要移动B数据，让出一个位置给A，这个有一定的开销。 更糟糕的是，本来要插入的页已经满了，那么就要申请一个新的页，然后挪一部分数据过去，这叫做页的分裂，这个开销更大。如果我们的sql变更是直接修改磁盘的数据，恰巧正好出现上面的问题，那么此时的效率就会很低，严重的话会造成超时，这也是上面更新的过程为什么先要加载对应的数据页到内存中，然后先更新内存中的数据的原因。对于mysql来说，所有的变更都必须先更新缓冲池中的数据，然后缓冲池中的脏页会以一定的频率被刷入磁盘（checkPoint机制），通过缓冲池来优化CPU和磁盘之间的鸿沟，这样就可以保证整体的性能不会下降太快。 为什么需要redo log？ 缓冲池可以帮助我们消除CPU和磁盘之间的鸿沟，checkpoint机制可以保证数据的最终落盘，然而由于checkpoint并不是每次变更的时候就触发的，而是master线程隔一段时间去处理的。所以最坏的情况就是刚写完缓冲池，数据库宕机了，那么这段数据就是丢失的，无法恢复。这样的话就不满足ACID中的D，为了解决这种情况下的持久化问题，InnoDB引擎的事务采用了WAL技术（Write-Ahead Logging），这种技术的思想就是先写日志，再写磁盘，只有日志写入成功，才算事务提交成功，这里的日志就是redo log。当发生宕机且数据未刷到磁盘的时候，可以通过redo log来恢复，保证ACID中的D，这就是redo log的作用。 redo log是如何实现的？ redo log的写入并不是直接写入磁盘的，redo log也有缓冲区的，叫做redo log buffer（重做日志缓冲），InnoDB引擎会在写redo log的时候先写redo log buffer，然后也是以一定的频率刷入到真正的redo log中，redo log buffer一般不需要特别大，它只是一个临时的容器，master线程会每秒将redo log buffer刷到redo log文件中，因此我们只要保证redo log buffer能够存下1s内的事务变更的数据量即可，以mysql5.7.23为例，这个默认是16M。 （编辑：云计算网_宿迁站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐