MySQL 页完全指南——浅入深出页的原理

之前写了一些关于 MySQL 的 InnoDB 存储引擎的文章,里面好几次都提到了页(Pages)这个概念,但是都只是简要的提了一下。例如之前在聊 InnoDB内存结构 时提到过,但当时的重点是内存架构,就没有展开深入。

我发现有好几次都需要提到页,那我就正好拿一篇来详细的讲讲 InnoDB 中的页。

页是什么

首先,我们需要知道,页(Pages)是 InnoDB 中管理数据的最小单元。Buffer Pool 中存的就是一页一页的数据。再比如,当我们要查询的数据不在 Buffer Pool 中时,InnoDB 会将记录所在的页整个加载到 Buffer Pool 中去;同样的,将 Buffer Pool 中的脏页刷入磁盘时,也是按照页为单位刷入磁盘的。

不了解 Buffer Pool 的、或者感兴趣的可以去文章开头给的链接熟悉一下

页的概览

我们往 MySQL 插入的数据最终都是存在页中的。在 InnoDB 中的设计中,页与页之间是通过一个双向链表连接起来。

而存储在页中的一行一行的数据则是通过单链表连接起来的。

继续阅读MySQL 页完全指南——浅入深出页的原理

缓存与数据库的双写一致性

这几天瞎逛,不知道在哪里瞟到了缓存的双写,就突然想起来这块虽然简单,但是细节上还是有足够多我们可以去关注的点。这篇文章就来详细聊聊双写一致性

首先我们知道,现在将高速缓存应用于业务当中已经十分常见了,甚至可能跟数据库的频率不相上下。你的用户量如果上去了,直接将一个裸的 MySQL 去扛住所有压力明显是不合理的。

这里的高速缓存,目前业界主流的就是 Redis 了,关于 Redis 相关的文章,之前也有聊过,在此就不赘述,感兴趣的可以看看:

额,不列出来我都没感觉关于 Redis 我居然写了这么多…言归正传。

在我们的业务中,普遍都会需要将一部分常用的热点数据(或者说不经常变但是又比较多的数据)放入 Redis 中缓存起来。下次业务来请求查询时,就可以直接将 Redis 中的数据返回,以此来减少业务系统和数据库的交互。

这样有两个好处,一个是能够降低数据库的压力,另一个自不必说,对相同数据来说能够有效的降低 API 的 RT(Response Time)。

继续阅读缓存与数据库的双写一致性