了解MySQL

MySQL整体架构

执行流程

ps：MySQL8去掉了缓存。

Parser（解析器）：将语句解析成解析树，并且通过预处理器判断解析树的语义是否正确，成功后会生成新的解析树。

Optimizer（优化器）：通过复杂算法实现尽可能的优化查询效率。

工作原理：根据解析树，生成不同的执行计划（Execution Plan），然后选择一种最优的执行计划。因为是基于开销（Cost）的优化器，所以会采取开销最小的执行计划。

但并不代表优化器生成的执行计划一定是最优的方案，也会存在覆盖不到的执行计划。

---

更新语句的执行流程

InnoDB的内存和磁盘架构图

Buffer Pool（缓冲池）：将磁盘读取到的数据缓存到Buffer Pool中。

1.读取数据的时候，会先判断数据是否存在Buffer Pool中，如果存在，则直接在Buffer Pool中读取；否则，从磁盘中读取，并写入到Buffer Pool中。

2.修改数据时，数据会先写入到Buffer Pool中，InnoDB会有后台线程把Buffer Pool中的数据写入到磁盘中。

引申问题：如果读取的数据较大时，Buffer Pool是一次性全部加载到内存中吗？

不是，因为磁盘I/O相对于内存来说很慢，特别是磁盘的随机读操作，I/O次数会更多。因此引入了预读取机制，当读取磁盘上的某块数据时，根据局部性原理（读取位置附近的数据可能会被用到），会一次性多读取一些数据保存到Buffer Pool中，通过空间换时间的思想，提升I/O效率。

Buffer Pool的预读机制

InnoDB设定了存储引擎从磁盘中读取数据的最小单位是页（16KB），即一次数据读取操作，会从磁盘中读取16KB的数据加载到Buffer Pool中。（ps：操作系统的页是4KB）

 InnoDB的预读算法：1.线性预读 和 随机预读

线性预读：将当前page所在extent的下一个extent提前预读到Buffer Pool中。

随机预读：将当前extent中剩余的page提前预读到Buffer Pool中。

InnoDB的逻辑存储结构：TableSpace（表空间） > Segment（段） > Extent（区，一般为1MB，包含64个Page） > Page（页，一般为16K） > Row（行）

 

缓存池空间管理

Buffer Pool 的空间默认是128M，可配置，官方建议配置机器内容的50%~70%左右。

如何保证Buffer Pool中的数据是热数据，涉及到数据淘汰算法，这里用的LRU。缓存池中有LRU链表，LRU链表分成两个部分。

 

 一部分是热数据，New Sublist。

一部分是冷数据，Old Sublist。

中间分割线是midpoint，通过分割线来实现对缓存池的冷热数据分离。

流程：所有新的数据页加载到Buffer Pool时，一律先放到冷数据区的head位置，不管是预读数据还是普通的读操作。如果是Old Sublist的数据被访问，则会移动到New Sublist中，没有被访问的数据会移动到Old Sublist，在实现数据淘汰时，则会淘汰Old Sublist的tail位置的数据。

配置：默认情况下，热数据区占5/8，冷数据区占3/8，可通过innodb_old_blocks_pct 配置，它表示冷数据区的大小，一般为37%。修改区间为5%~95%，值越小，就使得冷数据区没有被访问的数据淘汰速度更快。ps：一般生产环境的机器，内存比较大，一般会把innodb_old_blocks_pct 值调低，防止热数据被刷出内存

Q：如何解决数据被查询一次，后面基本用不到的情况？（数据被访问一次，导致它从冷数据区移动到热数据区，使得热数据区的数据被迫移动到冷数据区，从而被淘汰。这种情况会导致热数据区是低频的数据页，从而使得缓存命中率大大降低，如何解决？）

A：InnoDB指定了冷数据移动到热数据区的规则：如果数据页在LRU链表中的冷数据区存在的时间超过1秒，就把它移动到热数据区。

通过innodb_old_blocks_time 控制，默认是1秒。

LRU算法实现原理：

 Buffer Pool中的脏数据何时被刷盘？（当进行修改数据时，会先修改Buffer Pool中的数据，而此时内存的数据和磁盘数据不一致）

1.后台线程定时刷新 2.Buffer Pool内存不足时 3.Redo Log写满时 4.数据库正常关闭