前言
事情是这样的，在某乎的邀请回答中看到了这个问题：
–
然后当时我没多想就啪一下写下来这样的答案：
MySQL
MySQL 不完全入门指南
由于 MySQL 的整个体系太过于庞大，文章的篇幅有限，不能够完全的覆盖所有的方面。所以我会尽可能的从更加贴进我们日常使用的方式来进行解释。
小白眼中的 MySQL
首先，对于我们来说，MySQL 是个啥？我们从一个最简单的例子来回顾一下。
这可能就是最开始大家认知中的 MySQL。那 MySQL 中是怎么处理这个查询语句的呢？换句话说，它是如何感知到这串字符串是一个查询语句的？它是如何感知到该去哪张表中取数据？它是如何感知到该如何取数据？
到目前为止，都不知道。接下来我们一步一补来进行解析。
连接池
首先，要去 MySQL 执行命令，肯定是需要连接上 MySQL 服务器的，就像我们通过「用户名」和「密码」登陆网站一样。所以，我们首先要认识的就是连接池。
这种池化技术的作用很明显，复用连接，避免频繁的销毁、创建线程所带来的开销。除此之外，在这一层还可以根据你的账号密码对用户的合法性、用户的权限进行校验。
每一个连接都对应一个线程，「服务器」 和 「MySQL」 都一样，服务器的一个线程从服务器的连接池中取出一个连接，发起查询语句。MySQL 服务器的线程从连接池中取出一个线程，继续后续的流程。
那么后面的流程是啥呢？当然是分析 SQL 语句了。
继续阅读MySQL 中删除的数据都去哪儿了？
不知道大家有没有想过下面这件事？
我们平时调用
DELETE在 MySQL 中删除的数据都去哪儿了？
这还用问吗？当然是被删除了啊
那么这里又有个新的问题了，如果在 InnoDB 下，多事务并发的情况下，如果事务A删除了 id=1 的数据，同时事务B又去读取 id=1 的数据，如果这条数据真的被删除了，那 MVCC 拿啥数据返回给用户呢？
没错，这就需要了解一下 MySQL 的多版本并发的原理相关的东西，感兴趣的可以去看我之前写的[这篇文章]()。
所以，实际情况中，调用了 DELETE 语句删除的数据并不会真正的被物理删除，这条数据其实还在那，只不过被打上了一个标记，标记已删除。
MySQL 到底是如何做到多版本并发的？
之前的文章简单的介绍了 MySQL 的事务隔离级别，它们分别是：读未提交、读已提交、可重复读、串行化。这篇文章我们就来探索一下 MySQL 事务隔离级别的底层原理。
本篇文章针对 InnoDB 存储引擎
多版本并发控制
我们知道，读未提交会造成脏读、幻读、不可重复读，读已提交会造成幻读、不可重复读，可重复读可能会有幻读，和串行化就不会有这些问题。
那 InnoDB 到底是怎么解决这些问题的呢？又或者，你有没有想过造成脏读、幻读、不可重复读的底层最根本的原因是什么呢？
这就是今天要聊的主角——MVCC（Multi-Version Concurrent Controll），也叫多版本并发控制。InnoDB 是一个支持多事务并发的存储引擎，它能让数据库中的读-写操作能够并发的进行，避免由于加锁而导致读阻塞。
正是由于有了 MVCC，在事务B更新 id=1 的数据时，事务A读取 id=1 的操作才不会被阻塞。而不阻塞的背后则是不加锁的一致性读。那什么是一致性读？
啥是 MySQL 事务隔离级别？
之前发过一篇文章，简单了解 MySQL 中相关的锁，里面提到了，如果我们使用的 MySQL 存储引擎为 InnoDB ，并且其事务隔离级别是 RR 可重复读的话，是可以避免幻读的。
但是没想到，都 1202 年了都还有人杠，说 InnoDB 的 RR 隔离级别下会出现幻读，只能依靠 gap 和 next-key 这两个锁来防止幻读 ，最开始我还以为是他真的不知道这个点，就跟他聊，最后聊下来发现，发现是在钻牛角尖。
这个在下面讲到 可重复读 的隔离级别时会讲。
本来我觉得事务隔离级别这玩意儿太简单没啥可讲的，但是经过了上面这件事，我打算详细的把事务隔离给讲讲。接下来顺便就把 InnoDB 所有的事务隔离级别给搂一遍。
ACID
在聊事务隔离级别之前，我们需要知道 ACID 模型。
分别代表：
继续阅读InnoDB 表空间
这应该是 MySQL 原理中最底层的部分了，我们存在 MySQL 中的数据，到底在磁盘上长啥样。你可能会说，数据不都存储在聚簇索引中吗？但很遗憾，你并没有回答我的问题。我会再问你，那聚簇索引在磁盘上又长啥样？
就像 Redis 的 RDB 文件，最终落在磁盘上就是一个真真切切的 dump.rdb 文件，而 MySQL 就显得有点迷，我们只知道通过 SQL 去拿数据，并不知道数据最终是以什么方式进行存储的。当然，了解其底层的存储逻辑，并不仅仅是为了满足好奇心这么简单。
其底层的存储方式，会影响到聚簇索引中数据的存储，进而影响到 MySQL 的 DML（Data Manipulation Language） 性能，所以对底层存储逻辑有个清晰的认知，就能够在某些对性能有着极致追求的场景下，帮助我们对 MySQL 进行优化。
表在磁盘上到底长啥样
继续阅读MySQL 页完全指南——浅入深出页的原理
之前写了一些关于 MySQL 的 InnoDB 存储引擎的文章，里面好几次都提到了页（Pages）这个概念，但是都只是简要的提了一下。例如之前在聊 InnoDB内存结构 时提到过，但当时的重点是内存架构，就没有展开深入。
我发现有好几次都需要提到页，那我就正好拿一篇来详细的讲讲 InnoDB 中的页。
页是什么
首先，我们需要知道，页（Pages）是 InnoDB 中管理数据的最小单元。Buffer Pool 中存的就是一页一页的数据。再比如，当我们要查询的数据不在 Buffer Pool 中时，InnoDB 会将记录所在的页整个加载到 Buffer Pool 中去；同样的，将 Buffer Pool 中的脏页刷入磁盘时，也是按照页为单位刷入磁盘的。
不了解 Buffer Pool 的、或者感兴趣的可以去文章开头给的链接熟悉一下
页的概览
我们往 MySQL 插入的数据最终都是存在页中的。在 InnoDB 中的设计中，页与页之间是通过一个双向链表连接起来。
而存储在页中的一行一行的数据则是通过单链表连接起来的。
继续阅读深入剖析 MySQL 自增锁
之前的文章把 InnoDB 中的所有的锁都介绍了一下，包括意向锁、记录锁…自增锁巴拉巴拉的。但是后面我自己回过头去看的时候发现，对自增锁的介绍居然才短短的一段。
其实自增锁（AUTO-INC Locks）这块还是有很多值得讨论的细节，例如在并发的场景下，InnoDB 是如何保证该值正确的进行自增的，本章就专门来简单讨论一下 InnoDB 中的自增锁。
什么是自增锁
之前我们提到过，自增锁是一种比较特殊的表级锁。并且在事务向包含了 AUTO_INCREMENT 列的表中新增数据时就会去持有自增锁，假设事务 A 正在做这个操作，如果另一个事务 B 尝试执行 INSERT语句，事务 B 会被阻塞住，直到事务 A 释放自增锁。
这怎么说呢，说他对，但是他也不完全对。
继续阅读简单了解 MySQL 中相关的锁
本文主要是带大家快速了解 InnoDB 中锁相关的知识
为什么需要加锁
首先，为什么要加锁？我想我不用多说了，想象接下来的场景你就能 GET 了。
你在商场的卫生间上厕所，此时你一定会做的操作是啥？锁门。如果不锁门，上厕所上着上着，啪一下门就被打开了，可能大概也许似乎貌似有那么一丁点的不太合适。
数据也是一样，在并发的场景下，如果不对数据加锁，会直接破坏数据的一致性，并且如果你的业务涉及到钱，那后果就更严重了。
锁门表情包
锁的分类
在 InnoDB 中，都有哪些锁？其实你应该已经知道了很多了，例如面试中会问你存储引擎 MyISAM 和 InnoDB 的区别，你会说 MyIASM 只有表锁，但是 InnoDB 同时支持行锁和表锁。你可能还会被问到乐观锁和悲观锁的区别是啥。
锁的概念、名词很多，如果你没有对锁构建出一个完整的世界观，那么你理解起来就会比较有阻碍，接下来我们把这些锁给分一下类。
继续阅读浅入浅出 MySQL 索引
索引是什么？为什么要有mysql 索引，解决了什么问题，其底层的原理是什么？为什么使用B+树做为解决方案？用其他的像哈希索引或者B树不行吗？
简单了解索引
首先，索引（Index）是什么？如果我直接告诉你索引是数据库管理系统中的一个有序的数据结构，你可能会有点懵逼。
为了避免这种情况，我打算举几个例子来帮助你更容易的认识索引。
SH的全栈笔记 