搞懂MYSQL底层原理(二 硬盘结构)

Posted 2021-03-31 清新公鱼

一、System Tablespace

存储在一个叫ibdata1的文件中，其中包含：

1. InnoDB Data Dictionary，存储了元数据，比如表结构信息、索引等

2. Doublewrite Buffer 当Buffer Pool写入数据页时，不是直接写入到文件，而是先写入到这个区域。这样做的好处的是，一旦操作系统，文件系统或者mysql挂掉，可以直接从这个Buffer中获取数据。

3. Change Buffer 当Mysql shut down的时候，修改就会被存储在磁盘这里

4. Undo Logs 记录事务修改操作

二、File-Per-Table Tablespaces

每一张表都有一张 .ibd 的文件，存储数据和索引。

1. 有了每表文件表空间可以使得 ALTER TABLE与 TRUNCATE TABLE 性能得到很好的提升。比如 ALTER TABLE，相较于对驻留在共享表空间中的表，在修改表时，会进行表复制操作，这可能会增加表空间占用的磁盘空间量。此类操作可能需要与表中的数据以及索引一样多的额外空间。该空间不会像每表文件表空间那样释放回操作系统。

2. 可以在单独的存储设备上创建每表文件表空间数据文件，以进行I / O优化，空间管理或备份。这就意味着表数据与结构容易在不同数据库中迁移。

3. 当发生数据损坏，备份或二进制日志不可用或无法重新启动MySQL服务器实例时，存储在单个表空间数据文件中的表可以节省时间并提高成功恢复的机会。

当然有优点就有缺陷：

1. 存储空间的利用率低，会存在碎片，在Drop table的时候会影响性能（除非你自己管理了碎片）

2. 因为每个表分成各自的表文件，操作系统不能同时进行fsync一次性刷入数据到文件中

3. mysqld会持续保持每个表文件的 文件句柄， 以提供维持对文件的持续访问

三、General Tablespaces

1. 通用表空间又叫共享表空间，他可以存储多个表的数据

2. 如果存储相同数量的表，消耗的存储比 每表表空间 小

3. 在MySQL 5.7.24中弃用了将表分区放置在常规表空间中的支持，并且在将来的MySQL版本中将不再支持。

四、Temporary Tablespaces

存储在一个叫 ibtmp1 的文件中。正常情况下Mysql启动的时候会创建临时表空间，停止的时候会删除临时表空间。并且它能够自动扩容。

五、Undo Tablespaces

1. 提供修改操作的 原子性，即当修改到一半，出现异常，可以通过Undo 日志回滚。

2. 它存储了，事务开始前的原始数据与这次的修改操作。

3. Undo log 存在于回滚段（rollback segment）中，回滚段又存在系统表空间撤销表空间临时表空间中，如架构图所示。

总结一下，我们执行一句update SQL 会发生什么

1. 查询到我们要修改的那条数据，我们这里称做 origin，返给执行器

2. 在执行器中，修改数据，称为 modification

3. 将modification刷入内存，Buffer Pool的 Change Buffer

4. 引擎层：记录undo log （实现事务原子性）

5. 引擎层：记录redo log （崩溃恢复使用）

6. 服务层：记录bin log（记录DDL）

7. 返回更新成功结果

8. 数据等待被工作线程刷入磁盘
   

   Mysql更新语句执行流程

---

Bin log

说了 Undo、Redo也顺便说一下Bin log.

1. 这一个log和 innodb引擎没有多大关系，我们前面说的那两种日志，都在是innodb引擎层的。而Bin log是处于服务层的。所以他能被各个引擎所通用

2. 他的主要作用是什么呢？首先，Bin log 是以事件的形式，记录了各个 DDL DML 语句，它是一种逻辑意义上的日志。

3. 能够实现主从复制， 从服务器拿到主服务器的bin log日志，然后执行。

4. 做数据恢复，拿到某个时间段的日志，重新执行一遍。