MySQL数据持久化过程实例分析

这篇文章主要介绍“MySQL数据持久化过程实例分析”的相关知识，小编通过实际案例向大家展示操作过程，操作方法简单快捷，实用性强，希望这篇“MySQL数据持久化过程实例分析”文章能帮助大家解决问题。

1. 过程简述

理解MySQL数据的持久化过程，能很好的帮助我们加深对于MySQL底层的理解，在本文，我们以一种通俗的方式梳理一下这个过程，帮助大家建立起初步的认识，如果大家感兴趣，可以去深入学习与研究这个过程。

MySQL数据的存储总体上可以分为两部分，内存中的存储过程以及硬盘的持久化存储，这里，就涉及到了内存中buffer poll和redo log以及磁盘上的事务日志和表结构，在本文中，我们不具体解释每一部分的具体设计，只是给大家一个概念型的认识：

• buffer poll 是InnoDB引擎缓存池的一部分，我们这里可以简单理解为数据库从磁盘读进内存的内存块的缓存；

• redo log是内存中的逻辑日志，记录了事务的变更操作

• 事务日志是磁盘上的食物逻辑日志

• 表结构是真正存储数据的结构

2. 内存中的操作

buffer poll中有对于读入内存的数据的缓存，在查询命令执行时，会优先在缓存中查看是否命中，未命中就会从磁盘中将需要的数据读进来，缓存的管理使用的是改良的LRU算法，这里不做深入地介绍了。

当一条修改指令运行的时候，首先进行的是对于buffer poll中缓存的修改，被修改后的数据会被标记为脏页，同时，修改的操作也会记录在redo log中，我们常说的MVCC中的版本链就是借助redo log实现的。

需要注意的是，脏页不是立刻落到磁盘的，而是有可以设置的刷盘控制机制，例如，一个事务执行结算后立刻落盘，按照一定时间定期落盘等等。

在内存中的操作都是非持久化的，如果这时发生了意料之外的问题导致系统宕机，数据是还没有持久化的，所以理论上也不会对数据库造成破坏性的影响。

3. 磁盘的持久化

3.1 事务日志的作用

InnoDB在磁盘的持久化分为两步，第一步是逻辑日志的存储，之后再将日志中的数据刷进磁盘空间。

在讨论为什么要使用逻辑日志之前，我们需要简单理解随机IO与顺序IO的区别：

在读取磁盘数据的时候，有一个寻址的过程，即将探针移动到需要的位置，这个过程是磁盘IO的重要瓶颈之一。

顺序IO是指寻址的空间是连续的，移动距离很短，随机IO是指我们需要寻找的地址分布在各处，需要移动很长的距离。

所以，我们能很明晰的得出结论：将随机IO替换为顺序IO能有效的提高磁盘IO的效率，逻辑日志的作用正是如此，由于日志文件在磁盘上是连续的，相比于分布在各处的数据表信息，IO效率能高出很多。

只要我们在事务日志中完整更新了操作，那么这个事务就已经持久化成功了，后续会有专门负责的线程将日志信息存储到表结构中。

3.2 表结构的两步存储

日志信息存储到表结构的过程是分为两步进行的，首先，会在表头的缓存区域内进行数据更新，更新完成后，才会在对应的表结构中刷新。

两步存储的目的是保证数据存储的强一致性，防止在刷入磁盘的过程中，数据库宕机导致数据不完整。

表头的缓存区域以及表结构的存储块都有校验码来检验数据的完整性，如果前者完整，后者不完整，直接讲前者数据在后者中重新刷一份即可解决，如果前者不完整，说明从日志刷取的过程失败，重新刷取即可。

关于“MySQL数据持久化过程实例分析”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识，可以关注亿速云行业资讯频道，小编每天都会为大家更新不同的知识点。