感谢 我不⽣产知识，只是知识的搬运⼯。写作本⼩册的时间主要⽤在了两 个⽅⾯： 搞清楚事情的本质是什么。 这个过程就是研究源码、书籍和资料。 如何把我已经知道的知识表达出来。 这个过程就是我不停的在地上⾛过来⾛过去，梳理知识结构， 斟酌⽤词⽤句，不停的将已经写好的⽂章推倒重来，只是想给 ⼤家⼀个不错的⽤户体验。 这两个⽅⾯⽤的时间基本上是⼀半⼀半吧，在搞清楚事情的本质是什 么阶段，除了直接阅读MySQL的源码之外，查看参考资料也是⼀种⽐ 较偷懒的学习⽅式。本书只是MySQL进阶的⼀个⼊⻔，想了解更多关 于M

undo ⽇志 标签： MySQL 是怎样运⾏的 事务回滚的需求 我们说过事务需要保证原⼦性，也就是事务中的操作要么全部完成， 要么什么也不做。但是偏偏有些时候做到⼀半的时候会出⼀些情况， ⽐如： 情况⼀：事务执⾏过程中可能遇到各种错误，⽐如服务器本身 的错误，操作系统错误，甚⾄是突然断电导致的错误。 情况⼆：程序员可以在事务执⾏过程中⼿动输⼊ROLLBACK语 句结束当前的事务的执⾏。 这两种情况都会导致事务执⾏到⼀半就结束，但是事务执⾏过程中可 能已经修改了很多东⻄，为了保证事务的原⼦性，我们需要把东

redo ⽇志（下） 标签： MySQL 是怎样运⾏的 redo⽇志⽂件 redo⽇志刷盘时机 我们前边说mtr运⾏过程中产⽣的⼀组redo⽇志在mtr结束时会被复 制到log buffer中，可是这些⽇志总在内存⾥呆着也不是个办法， 在⼀些情况下它们会被刷新到磁盘⾥，⽐如： log buffer空间不⾜时 log buffer的⼤⼩是有限的（通过系统变量 innodb_log_buffer_size指定），如果不停的往这个有限 ⼤⼩的log buffer⾥塞⼊⽇志，很快它就会被填满。设计 InnoDB的

redo⽇志（上） 标签： MySQL是怎样运⾏的 事先说明 本⽂以及接下来的⼏篇⽂章将会频繁的使⽤到我们前边唠叨的 InnoDB记录⾏格式、⻚⾯格式、索引原理、表空间的组成等各种基 础知识，如果⼤家对这些东⻄理解的不透彻，那么阅读下边的⽂字可 能会有些吃⼒，为保证您的阅读体验，请确保⾃⼰已经掌握了我前边 唠叨的这些知识。 redo⽇志是个啥 我们知道InnoDB存储引擎是以⻚为单位来管理存储空间的，我们进 ⾏的增删改查操作其实本质上都是在访问⻚⾯（包括读⻚⾯、写⻚ ⾯、创建新⻚⾯等操作）。我们前边唠叨B

事务简介 标签： MySQL 是怎样运⾏的 事务的起源 对于⼤部分程序员来说，他们的任务就是把现实世界的业务场景映射 到数据库世界。⽐如银⾏为了存储⼈们的账户信息会建⽴⼀ 个account表： CREATE TABLE account ( id INT NOT NULL AUTO_INCREMENT COMMENT '⾃增 id', name VARCHAR(100) COMMENT '客户名称', balance INT COMMENT '余额', PRIMARY KEY

InnoDB 的 Buffer Pool 标签： MySQL 是怎样运⾏的 缓存的重要性 通过前边的唠叨我们知道，对于使⽤InnoDB作为存储引擎的表来 说，不管是⽤于存储⽤户数据的索引（包括聚簇索引和⼆级索引）， 还是各种系统数据，都是以⻚的形式存放在表空间中的，⽽所谓的表 空间只不过是InnoDB对⽂件系统上⼀个或⼏个实际⽂件的抽象，也 就是说我们的数据说到底还是存储在磁盘上的。但是各位也都知道， 磁盘的速度慢的跟乌⻳⼀样，怎么能配得上“快如⻛，疾如电”的CPU 呢？所以InnoDB存储引擎在处理客户

otpimizer trace 表的神奇功效 标签： MySQL 是怎样运⾏的 对于MySQL 5.6以及之前的版本来说，查询优化器就像是⼀个⿊盒 ⼦⼀样，你只能通过EXPLAIN语句查看到最后优化器决定使⽤的执 ⾏计划，却⽆法知道它为什么做这个决策。这对于⼀部分喜欢刨根问 底的⼩伙伴来说简直是灾难：“我就觉得使⽤其他的执⾏⽅案⽐ EXPLAIN输出的这种⽅案强，凭什么优化器做的决定和我想的不⼀ 样呢？” 在MySQL 5.6以及之后的版本中，设计MySQL的⼤叔贴⼼的为这部 分⼩伙伴提出了⼀个optim

Explain 详解（下） 标签： MySQL 是怎样运⾏的 执⾏计划输出中各列详解 本章紧接着上⼀节的内容，继续唠叨EXPLAIN语句输出的各个列的 意思。 Extra 顾名思义，Extra列是⽤来说明⼀些额外信息的，我们可以通过这些 额外信息来更准确的理解MySQL到底将如何执⾏给定的查询语 句。MySQL提供的额外信息有好⼏⼗个，我们就不⼀个⼀个介绍了 （都介绍了感觉我们的⽂章就跟⽂档差不多了～），所以我们只挑⼀ 些平时常⻅的或者⽐较重要的额外信息介绍给⼤家哈。 No tables used 当查询

Explain 详解（上） 标签： MySQL 是怎样运⾏的 ⼀条查询语句在经过MySQL查询优化器的各种基于成本和规则的优化 会后⽣成⼀个所谓的执⾏计划，这个执⾏计划展示了接下来具体执⾏ 查询的⽅式，⽐如多表连接的顺序是什么，对于每个表采⽤什么访问 ⽅法来具体执⾏查询等等。设计MySQL的⼤叔贴⼼的为我们提供了 EXPLAIN语句来帮助我们查看某个查询语句的具体执⾏计划，本章 的内容就是为了帮助⼤家看懂EXPLAIN语句的各个输出项都是⼲嘛 使的，从⽽可以有针对性的提升我们查询语句的性能。 如果我们想看

基于规则的优化 标签： MySQL 是怎样运⾏的 ⼤家别忘了MySQL本质上是⼀个软件，设计MySQL的⼤叔并不能要求 使⽤这个软件的⼈个个都是数据库⾼⾼⼿，就像我写这本书的时候并 不能要求各位在学之前就会了⾥边⼉的知识。 吐槽⼀下：都会了的⼈谁还看呢，难道是为了精神上受感化？ 也就是说我们⽆法避免某些同学写⼀些执⾏起来⼗分耗费性能的语 句。即使是这样，设计MySQL的⼤叔还是依据⼀些规则，竭尽全⼒的 把这个很糟糕的语句转换成某种可以⽐较⾼效执⾏的形式，这个过程 也可以被称作查询重写（就是⼈家觉得你写的语

InnoDB 统计数据是如何收集的 标签： MySQL 是怎样运⾏的 我们前边唠叨查询成本的时候经常⽤到⼀些统计数据，⽐如通过 SHOW TABLE STATUS可以看到关于表的统计数据，通过SHOW INDEX可以看到关于索引的统计数据，那么这些统计数据是怎么来的 呢？它们是以什么⽅式收集的呢？本章将聚焦于InnoDB存储引擎的 统计数据收集策略，看完本章⼤家就会明⽩为啥前边⽼说InnoDB的 统计信息是不精确的估计值了（⾔下之意就是我们不打算介绍 MyISAM存储引擎统计数据的收集和存储⽅式，有想了解

基于成本的优化 标签： MySQL 是怎样运⾏的 什么是成本 我们之前⽼说MySQL执⾏⼀个查询可以有不同的执⾏⽅案，它会选择 其中成本最低，或者说代价最低的那种⽅案去真正的执⾏查询。不过 我们之前对成本的描述是⾮常模糊的，其实在MySQL中⼀条查询语句 的执⾏成本是由下边这两个⽅⾯组成的： I/O成本 我们的表经常使⽤的MyISAM、InnoDB存储引擎都是将数据和 索引都存储到磁盘上的，当我们想查询表中的记录时，需要先 把数据或者索引加载到内存中然后再操作。这个从磁盘到内存 这个加载的过程损耗的时间称

连接的原理 标签： MySQL 是怎样运⾏的 搞数据库⼀个避不开的概念就是Join，翻译成中⽂就是连接。相信 很多⼩伙伴在初学连接的时候有些⼀脸懵逼，理解了连接的语义之后 ⼜可能不明⽩各个表中的记录到底是怎么连起来的，以⾄于在使⽤的 时候常常陷⼊下边两种误区： 误区⼀：业务⾄上，管他三七⼆⼗⼀，再复杂的查询也⽤在⼀ 个连接语句中搞定。 误区⼆：敬⽽远之，上次 DBA 那给报过来的慢查询就是因为 使⽤了连接导致的，以后再也不敢⽤了。 所以本章就来扒⼀扒连接的原理。考虑到⼀部分⼩伙伴可能忘了连接 是个啥或者压

单表访问⽅法 标签： MySQL 是怎样运⾏的 对于我们这些MySQL的使⽤者来说，MySQL其实就是⼀个软件，平时 ⽤的最多的就是查询功能。DBA时不时丢过来⼀些慢查询语句让优 化，我们如果连查询是怎么执⾏的都不清楚还优化个⽑线，所以是时 候掌握真正的技术了。我们在第⼀章的时候就曾说过，MySQL Server有⼀个称为查询优化器的模块，⼀条查询语句进⾏语法解析 之后就会被交给查询优化器来进⾏优化，优化的结果就是⽣成⼀个所 谓的执⾏计划，这个执⾏计划表明了应该使⽤哪些索引进⾏查询，表 之间的连接顺序是啥

MySQL 的数据⽬录 标签： MySQL 是怎样运⾏的 数据库和⽂件系统的关系 我们知道像InnoDB、MyISAM这样的存储引擎都是把表存储在磁盘 上的，⽽操作系统⽤来管理磁盘的那个东东⼜被称为⽂件系统，所以 ⽤专业⼀点的话来表述就是：像 InnoDB 、 MyISAM 这样的存储引 擎都是把表存储在⽂件系统上的。当我们想读取数据的时候，这些存 储引擎会从⽂件系统中把数据读出来返回给我们，当我们想写⼊数据 的时候，这些存储引擎会把这些数据⼜写回⽂件系统。本章就是要唠 叨⼀下InnoDB和MyISAM这

B+树索引 标签： MySQL是怎样运⾏的 前边我们详细唠叨了InnoDB数据⻚的7个组成部分，知道了各个数 据⻚可以组成⼀个双向链表，⽽每个数据⻚中的记录会按照主键值从 ⼩到⼤的顺序组成⼀个单向链表，每个数据⻚都会为存储在它⾥边⼉ 的记录⽣成⼀个⻚⽬录，在通过主键查找某条记录的时候可以在⻚⽬ 录中使⽤⼆分法快速定位到对应的槽，然后再遍历该槽对应分组中的 记录即可快速找到指定的记录（如果你对这段话有⼀丁点⼉疑惑，那 么接下来的部分不适合你，返回去看⼀下数据⻚结构吧）。⻚和记录 的关系示意图如下： 其中⻚a

InnoD 数据⻚结构 标签： MySQL 是怎样运⾏的 不同类型的⻚简介 前边我们简单提了⼀下⻚的概念，它是InnoDB管理存储空间的基本 单位，⼀个⻚的⼤⼩⼀般是16KB。InnoDB为了不同的⽬的⽽设计了 许多种不同类型的⻚，⽐如存放表空间头部信息的⻚，存放Insert Buffer信息的⻚，存放INODE信息的⻚，存放undo⽇志信息的⻚等 等等等。当然了，如果我说的这些名词你⼀个都没有听过，就当我放 了个屁吧～ 不过这没有⼀⽑钱关系，我们今⼉个也不准备说这些类 型的⻚，我们聚焦的是那些存放我们表

InnoDB记录存储结构 标签： MySQL 是怎样运⾏的 准备⼯作 到现在为⽌，MySQL对于我们来说还是⼀个⿊盒，我们只负责使⽤客 户端发送请求并等待服务器返回结果，表中的数据到底存到了哪⾥？ 以什么格式存放的？MySQL是以什么⽅式来访问的这些数据？这些问 题我们统统不知道，对于未知领域的探索向来就是社会主义核⼼价值 观中的⼀部分，作为新⼀代社会主义接班⼈，不把它们搞懂怎么⽀援 祖国建设呢？ 我们前边唠叨请求处理过程的时候提到过，MySQL服务器上负责对表 中数据的读取和写⼊⼯作的部分是存储引擎，⽽

初识MySQL 标签： MySQL是怎样运⾏的 MySQL的客户端／服务器架构 以我们平时使⽤的微信为例，它其实是由两部分组成的，⼀部分是客 户端程序，⼀部分是服务器程序。客户端可能有很多种形式，⽐如⼿ 机APP，电脑软件或者是⽹⻚版微信，每个客户端都有⼀个唯⼀的⽤ 户名，就是你的微信号，另⼀⽅⾯，腾讯公司在他们的机房⾥运⾏着 ⼀个服务器软件，我们平时操作微信其实都是⽤客户端来和这个服务 器来打交道。⽐如狗哥⽤微信给猫爷发了⼀条消息的过程其实是这样 的： 1. 消息被客户端包装了⼀下，添加了发送者和接受者

MySQL是怎样运行的、从根上理解MySQL