简单了解 TiDB 架构

一、前言

大家如果看过我之前发过的文章就知道，我写过很多篇关于 MySQL 的文章，从我的 Github 汇总仓库 中可以看出来：

MySQL 表数据多久刷一次盘

前言

事情是这样的，在某乎的邀请回答中看到了这个问题：

-

然后当时我没多想就啪一下写下来这样的答案：

这个其实要通过 MySQL 后台线程来刷的，在 Buffer Pool 中被修改的过的 Page（页）都会被标记成脏页，放到一个链表（Flush 链表）里。

然后 MySQL 通过启动后台线程，在满足条件时将 Flush 链表中的脏页刷入磁盘。

满足的条件是：脏页的数量达到了 Buffer Pool 中页数量的 10%，当然 10% 这个值是可变的，通过配置项 innodb_max_dirty_pages_pct_lwm 来配置的，其默认值为 10%，并且这个值也必须小于另一个配置 innodb_max_dirty_pages_pct 的值（90%）。

至于启多少个线程，则是由另一个变量 innodb_page_cleaners 来控制的，默认是 4.一般都不会去改这个。

大概就是这样。

MySQL 不完全入门指南

由于 MySQL 的整个体系太过于庞大，文章的篇幅有限，不能够完全的覆盖所有的方面。所以我会尽可能的从更加贴进我们日常使用的方式来进行解释。

小白眼中的 MySQL

首先，对于我们来说，MySQL 是个啥？我们从一个最简单的例子来回顾一下。

这可能就是最开始大家认知中的 MySQL。那 MySQL 中是怎么处理这个查询语句的呢？换句话说，它是如何感知到这串字符串是一个查询语句的？它是如何感知到该去哪张表中取数据？它是如何感知到该如何取数据？

MySQL 中删除的数据都去哪儿了？

不知道大家有没有想过下面这件事？

我们平时调用 DELETE 在 MySQL 中删除的数据都去哪儿了？

这还用问吗？当然是被删除了啊

那么这里又有个新的问题了，如果在 InnoDB 下，多事务并发的情况下，如果事务A删除了 id=1 的数据，同时事务B又去读取 id=1 的数据，如果这条数据真的被删除了，那 MVCC 拿啥数据返回给用户呢？

MySQL 到底是如何做到多版本并发的？

之前的文章简单的介绍了 MySQL 的事务隔离级别，它们分别是：读未提交、读已提交、可重复读、串行化。这篇文章我们就来探索一下 MySQL 事务隔离级别的底层原理。

本篇文章针对 InnoDB 存储引擎

多版本并发控制

我们知道，读未提交会造成脏读、幻读、不可重复读，读已提交会造成幻读、不可重复读，可重复读可能会有幻读，和串行化就不会有这些问题。

那 InnoDB 到底是怎么解决这些问题的呢？又或者，你有没有想过造成脏读、幻读、不可重复读的底层最根本的原因是什么呢？

啥是 MySQL 事务隔离级别？

之前发过一篇文章，简单了解 MySQL 中相关的锁，里面提到了，如果我们使用的 MySQL 存储引擎为 InnoDB ，并且其事务隔离级别是 RR 可重复读的话，是可以避免幻读的。

但是没想到，都 1202 年了都还有人杠，说 InnoDB 的 RR 隔离级别下会出现幻读，只能依靠 gap 和 next-key 这两个锁来防止幻读 ，最开始我还以为是他真的不知道这个点，就跟他聊，最后聊下来发现，发现是在钻牛角尖。

InnoDB 表空间

这应该是 MySQL 原理中最底层的部分了，我们存在 MySQL 中的数据，到底在磁盘上长啥样。你可能会说，数据不都存储在聚簇索引中吗？但很遗憾，你并没有回答我的问题。我会再问你，那聚簇索引在磁盘上又长啥样？

就像 Redis 的 RDB 文件，最终落在磁盘上就是一个真真切切的 dump.rdb 文件，而 MySQL 就显得有点迷，我们只知道通过 SQL 去拿数据，并不知道数据最终是以什么方式进行存储的。当然，了解其底层的存储逻辑，并不仅仅是为了满足好奇心这么简单。

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

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

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

深入剖析 MySQL 自增锁

之前的文章把 InnoDB 中的所有的锁都介绍了一下，包括意向锁、记录锁...自增锁巴拉巴拉的。但是后面我自己回过头去看的时候发现，对自增锁的介绍居然才短短的一段。

其实自增锁（AUTO-INC Locks）这块还是有很多值得讨论的细节，例如在并发的场景下，InnoDB 是如何保证该值正确的进行自增的，本章就专门来简单讨论一下 InnoDB 中的自增锁。

简单了解 MySQL 中相关的锁

本文主要是带大家快速了解 InnoDB 中锁相关的知识

为什么需要加锁

首先，为什么要加锁？我想我不用多说了，想象接下来的场景你就能 GET 了。

你在商场的卫生间上厕所，此时你一定会做的操作是啥？锁门。如果不锁门，上厕所上着上着，啪一下门就被打开了，可能大概也许似乎貌似有那么一丁点的不太合适。

数据也是一样，在并发的场景下，如果不对数据加锁，会直接破坏数据的一致性，并且如果你的业务涉及到钱，那后果就更严重了。