详细了解 InnoDB 内存结构及其原理

最近发现,文章太长的话,包含的信息量较大, 并且需要更多的时间去阅读。而大家看文章,应该都是利用的一些碎片时间。所以我得出一个结论,文章太长不太利于大家的吸收和消化。所以我之后会减少文章的长度,2-3K字就差不多,也能够快速的阅读完。

之前写过一篇文章「简单了解InnoDB原理」,现在回过头看,其实里面只是把缓冲池(Buffer Pool),重做日志缓冲(Redo Log Buffer)、插入缓冲(Insert Buffer)和自适应哈希索引(Adaptive Hash Index)等概念简单的介绍了一下。

除此之外还聊了一下MySQL和InnoDB的日志,和两次写,总的来说算是一个入门级别的介绍,这篇文章就来详细介绍一下InnoDB的内存结构

InnoDB内存结构

其大致结构如下图。

InnoDB内存的两个主要区域分别为Buffer PoolLog Buffer,此处的Log Buffer目前是用于缓存Redo Log。而Buffer Pool则是MySQL或者说InnoDB中,十分重要、核心的一部分,位于主存。这也是为什么其访问数据的效率高,你可以暂时把它理解成Redis那样的内存数据库,因为我们更新和新增当然它不是,只是这样会更加方便我们理解。

继续阅读详细了解 InnoDB 内存结构及其原理

基于Redo Log和Undo Log的MySQL崩溃恢复流程

在之前的文章「简单了解InnoDB底层原理」聊了一下MySQL的Buffer Pool。这里再简单提一嘴,Buffer Pool是MySQL内存结构中十分核心的一个组成,你可以先把它想象成一个黑盒子。

黑盒下的更新数据流程

当我们查询数据的时候,会先去Buffer Pool中查询。如果Buffer Pool中不存在,存储引擎会先将数据从磁盘加载到Buffer Pool中,然后将数据返回给客户端;同理,当我们更新某个数据的时候,如果这个数据不存在于Buffer Pool,同样会先数据加载进来,然后修改修改内存的数据。被修改过的数据会在之后统一刷入磁盘。

MySQL 崩溃恢复

这个过程看似没啥问题,实则不讲武德。假设我们修改Buffer Pool中的数据成功,但是还没来得及将数据刷入磁盘MySQL就挂了怎么办?按照上图的逻辑,此时更新之后的数据只存在于Buffer Pool中,如果此时MySQL宕机了,这部分数据将会永久的丢失;

继续阅读基于Redo Log和Undo Log的MySQL崩溃恢复流程

深入了解MySQL主从复制的原理

0. 主从复制

首先主从复制是什么?简单来说是让一台MySQL服务器去复制另一台MySQL的数据,使两个服务器的数据保持一致。

这种方式与Redis的主从复制的思路没有太大的出入。如果你对Redis的主从复制感兴趣可以去看看《Redis的主从复制》。那既然Redis和MySQL都采用了复制这种方式,主从复制所带来的意义是什么呢?

通过复制功能,构建一个或者多个从库,可以提高数据库的高可用性可扩展性,同时实现负载均衡。当主库发生故障时,可以快速的切到其某一个从库,并将该从库提升为主库,因为数据都一样,所以不会影响系统的运行;当MySQL服务器需要扛住更多的读请求时,可以把读请求的流量分流到各个从库上去,写请求则转发给主库,形成读写分离的架构,来提供更好的读扩展和请求的负载均衡。

读写分离的架构应用的其实非常广泛,就比如MySQL,还有Redis,以及我们熟悉的Zookeeper,Zookeeper的Follower收到读请求不会自己处理,而是会将读请求转发给Leader,感兴趣的可以自己下来了解一下,这里就不偏题了。

继续阅读深入了解MySQL主从复制的原理

简单了解InnoDB底层原理

存储引擎

很多文章都是直接开始介绍有哪些存储引擎,并没有去介绍存储引擎本身。那么究竟什么是存储引擎?不知道大家有没有想过,MySQL是如何存储我们丢进去的数据的?

其实存储引擎也很简单,我认为就是一种存储解决方案,实现了新增数据、更新数据和建立索引等等功能。

有哪些已有的存储引擎可以让我们选择呢?

InnoDB、MyISAM、Memory、CSV、Archive、Blackhole、Merge、Federated、Example

种类很多,但是常用的存储引擎目前就只有InnoDB和MyISAM,我也会着重来介绍这两种存储引擎。

InnoDB是目前使用最广的MySQL存储引擎,MySQL从5.5版本开始InnoDB就已经是默认的存储引擎了。那你知道为什么InnoDB被广泛的使用呢?先把这个问题放一放,我们先来了解一下InnoDB存储引擎的底层原理。

继续阅读简单了解InnoDB底层原理