MySQL 学习总结 之 初步了解 InnoDB 存储引擎的架构设计
一、存储引擎
上节我们最后说到，SQL的执行计划是执行器组件调用存储引擎的接口来完成的。
那我们可以理解为：MySQL这个数据库管理系统是依靠存储引擎与存放数据的磁盘文件进行交互的。
那么MySQL有哪些存储引擎呢？
主要有MyISAM、InnoDB、Memory等等。而现在互联网中，基本都是使用InnoDB存储引擎，所以接下来我将简单总结自己关于InnoDB存储引擎的学习，比较简单的介绍InnoDB存储引擎里面的组件。
二、缓冲池
我们现在都知道了，数据库的数据是存放在磁盘文件中的。
那么，我们每次对表的增删改查都是直接在磁盘文件里面操作吗？
答案：不是的！
因为磁盘文件的随机读写的性能是非常差的，如果所有操作都在磁盘中进行，那么就不会有高性能MySQL的说法了，MySQL也不能支持高并发，也不会在互联网中如此的流行。
这时候要引入InnoDB存储引擎最重要的一个组件，就是缓冲池（BufferPool），它是一个非常重要的内存结构。它是内存里面的，凭借着内存非常高性能的读写，使得MySQL能够支持高并发。
缓冲池（BufferPool）的使用原理：
我们先复习一下MySQL接收请求的过程。
①、MySQL的工作线程专门监听数据库连接池的连接，有连接就获取连接中的SQL语句。
②、然后将SQL语句交给SQL接口去处理，SQL接口里会进行下面的一系列流程。
③、查询解析器将SQL语句解析成MySQL能理解的东西。
④、接着查询优化器去为SQL语句制定一套最优的执行计划。
⑤、执行器会根据执行计划去调用存储引擎的接口。
上面是上篇文章总结到的东西，那么存储引擎的接口是怎么进行增删改查的呢？以更新操作为例，其他的同理。
首先，存储引擎会先判断更新SQL对应的数据行是否在缓冲池（BufferPool）里面。如果在的话就直接在缓冲池（BufferPool）里更新数据然后返回；如果不在，则从磁盘文件里读取数据到缓冲池（BufferPool）里，然后进行更新操作，最后再返回结果。
三、undo日志文件
我们都知道，在事务中，事务提交前是可以随时回滚对数据的更新的。那么是依靠什么来做的呢？
依靠的是undo日志文件。
undo日志文件的使用原理：
更新数据为例：
假如你更新某行id=100的数据，将字段name由原来的“张三”改为“李四”，那么此时会将"id=10"和“name=张三”这两个关键信息写入undo日志文件中。
当你事务提交前需要回滚，就会从undo日志文件中找到这两个关键字，然后进行更新操作的回滚。
四、redologbuffer
上面说到，所有的增删改查操作其实是在缓冲池里面进行的，所以其实对数据的修改并没有立刻落实到磁盘文件里面。
那么有一个问题：在缓冲池的脏数据刷回磁盘文件中前，MySQL宕机了怎么办？
此时InnoDB存储引擎提供了一个非常重要的组件，就是redologbuffer组件.，它也是内存里的一块缓冲区。
redologbuffer的使用原理：
还是以上面的更新操作为例，当数据更新后，会记录下数据更新的的关键信息，对应的就是redo日志，然后写入redologbuffer里。
但是还是会有一个问题，上面说到，redologbuffer也是在内存里的。那当MySQL宕机时，由于内存里的所有数据都会丢失，所以缓冲池的脏数据和redologbuffer的日志还是会全部丢失。
这样会造成一种情况，客户端收到更新成功的信息了，但是最后数据库里头的数据还是没更新成功。
所以，redologbuffer还有一个刷盘策略。正常是，当事务提交时，会将redologbuffer里的redo日志刷回到磁盘中，这样就不用担心，事务提交成功，但是更新数据可能会丢失的问题了。即使在缓冲池（BufferPool）的脏数据刷回磁盘前，MySQL宕机了，也不会丢失数据，因为MySQL重启时可以根据磁盘中的redo日志恢复之前所有脏数据的更新。
总结
以上所述是小编给大家介绍的MySQL学习总结之初步了解InnoDB存储引擎的架构设计，希望对大家有所帮助！
声明：本文内容来源于网络，版权归原作者所有，内容由互联网用户自发贡献自行上传，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任。如果您发现有涉嫌版权的内容，欢迎发送邮件至：czq8825#qq.com（发邮件时，请将#更换为@）进行举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。