MySQL阶段一笔记：体系结构与内存结构（不全是原创）

目录

一、mysql组成

二、mysql内存

三、MySQL文件结构

四、innoDB存储结构

五、innoDB内存结构

六、innoDB预读机制：

七、innoDb特性:

 八、sql执行

九、redo log和bin log

---

一、mysql组成

1. 连接池：缓存数据库连接，提升服务器性能
2. 管理工具和服务：用于备份恢复、集群、mysql复制？

·     1）mysql复制：、

• 包括主-主、主-从、半同步
• 复制原理：记录所有操作的（增删改查insert,update,delete,create/alter/drop table, grant）的bin（二进制）日志，将bin日志从主服务器复制到从服务器，bin日志只有增删改、没有查

    2） 复制过程：
        主节点必须启用二进制日志，记录任何修改了数据库数据的事件。
从节点开启一个线程（I/O Thread)把自己扮演成 mysql 的客户端，通过 mysql 协议，请求主节点的二进制日志文件中的事件
        主节点启动一个线程（dump Thread），检查自己二进制日志中的事件，跟对方请求的位置对比，如果不带请求位置参数，则主节点就会从第一个日志文件中的第一个事件一个一个发送给从节点。
        从节点接收到主节点发送过来的数据把它放置到中继日志（Relay log）文件中。并记录该次请求到主节点的具体哪一个二进制日志文件内部的哪一个位置（主节点中的二进制文件会有多个，在后面详细讲解）。
        从节点启动另外一个线程（sql Thread ），把 Relay log 中的事件读取出来，并在本地再执行一次。

1. SQL接口：接收用户指令，并返回结果；执行sql语句，select 。。。
2. 解析器：用Lex和YACC脚本解析，1）将sql语句分解成数据结构，sql按照这个结构执行2）不符合数据结构的sql，解析会报错
3. 优化器：选取（where指定条件）-投影（映射指定字段）-联接（将选取和投影的结果整合）
4. 缓存器：查询先从查询缓存读数据，LRU？算法将冷端数据溢出，没写到磁盘的数据页，叫脏页，脏页需要刷新到磁盘中吗？  表缓存、记录缓存、key缓存、、、LRU算法淘汰Lru列表中末位的页(未使用的页，就是没有修改过，不是脏页，未使用的页是否直接丢到），脏页是同时存在LRU list和flush list中；

PS：扈老师说的日志有，undo日志（回滚）、redo日志（重新执行日志）、bin日志（mysql复制）

二、mysql内存

1. 线程内存：Master Thread、IO Thread、Purage Thread？、Page Cleaner Thread
2. CheckPoint技术：先重做日志，再修改内存中的数据，最后定时刷新到磁盘

三、MySQL文件结构

1. 参数文件，为啥有多个，只有一个不行吗？PS：扈老师说，多个参数文件是为了个性化配置，比如配置多个JDK版本，root用JDK7，view用JDK8，如果当前参数文件找不到内容，继续找上级，之道找到默认参数文件
2. socket文件：当用UNIX域套接字方式进行连接的时候需要的文件
3. 表结构文件：.frm后缀的文件，就是表结构文件
4. 存储引擎文件：每张表都有独立的表空间，并且可以不启用吗？（可以不启用）查看数据库是否启用独立表空间：
   show variables like ‘innodb_file_per_table’;查看，innodb_file_per_table=ON,表示启用了独立表空间

四、innoDB存储结构

表空间-》段-》区-》页-》行

1区=64页，且是连续的页，不可修改

1页=16kb

1区=64页*16kb=1M

1页=7992行

五、innoDB内存结构

mysql的数据在磁盘和内存中的存储结构是采用B+树的数据结构

B+树：

        B+树的非叶子节点不保存关键字记录的指针，只进行数据索引，这样使得B+树每个非叶子节点所能保存的关键字大大增加

        B+树叶子节点保存了父节点的所有关键字记录的指针，所有数据地址必须要到叶子节点才能获取到。所以每次数据查询的次数都一样

        B+树叶子节点的关键字从小到大有序排列，左边结尾数据都会保存右边节点开始数据的指针

        非叶子节点的子节点数=关键字数（来源百度百科）（根据各种资料 这里有两种算法的实现方式，另一种为非叶节点的关键字数=子节点数-1（来源维基百科)，虽然他们数据排列结构不一样，但其原理还是一样的Mysql 的B+树是用第一种方式实现）

六、innoDB预读机制：

mysql读数据：从磁盘读到内存，读取单条数据，也是将数据所在页一起读到内存中，用线性预读或者随机预读两种方式读取

线性预读，是读下一个区；

随机预读，是读当前区剩下的所有页

七、innoDb特性:

1. 插入缓存
2. doublewrite
3. 自适应hash索引（AHI）
4. 异步IO
5. 刷新邻接页

 八、sql执行

1. redo log是自己执行flush 将sql语句写入到OS cache，然后fsync到磁盘；bin log是并将sql语句写入到OS cache，然后执行fasync将sql语句写入到磁盘
2. sql语句从OScache写入到磁盘，叫内核线程，数据写入到磁盘，是有内核线程执行的
3. 先redo log，再bin log，然后提交事务

       mysql执行增删改操作时，innoDB 引擎执行步骤：

1. 执行器拿到sql后，将要修改的数据从磁盘拿到内存中，buffer pool
2. 修改数据前，将修改前的sql语句写到undo log
3. undo log写好后，直接修改内存数据
4. 修改数据后，将修改后的sql语句写到redo log
5. 将redo log，先flush到OS cache，然后操作系统会DMA异步到磁盘中  （prepare阶段，并告诉执行器已经执行完成了，随时可以commit）
6. 更新bin log，将bin log写到OS cache，然后操作系统会DMA异步到磁盘中
7. 提交事务（引擎的提交事务接口，讲redo log的状态由prepare状态改为commit状态）

九、redo log和bin log

1、redo log：记录更新动作，修改哪个页，哪行的动作，物理日志

      bin log：记录sql语句，逻辑日志

redo log中：

write pos 和 checkpoint 之间的是log上还空着的部分，可以用来记录新的操作。如果 write pos 追上 checkpoint，表示log满了，

这时候不能再执行新的更新，得停下来先擦掉一些记录，把 checkpoint 推进一下。有了 redo log，InnoDB 就可以保证即使数据库

发生异常重启，之前提交的记录都不会丢失，这个能力称为 crash-safe

2、redo log buffer：一个事务中有多次更新操作，更新一次内存的数据后，将更新记录，放入redo log buffer中，待多次更新全部执行后，并且commit后，将redo log buffer中的全部更新记录写到redo log中

第三篇文章说：

在一个事务中 可能有多个插入操作 日志要写入多次

beging

insert into t1..

insert into t2...

插入的过程中,生成的日志都要先保存起来,等到commit的时候才写到redolog中

所以redo log buffer 就是一块内存  第一个插入后 内存被修改 redo log buffer里也写入了日志

但是真正把日志写到redo log 文件中的是 执行commit操作时做的

可是，commit不是在prepare后吗，prepare的时候，更新动作已经成功写入到redo log中了啊？

我笨了，这个commit指的是当前这个事务的commit，而不是redo log的commit