一起走进MySQL引擎是如何工作的
MySQL服务器服务器负责对数据进行读取与存人的部分工作是存储引擎，服务器支持多种存储引擎：InnoDB、MyISAM、Mymory等。MySQL默认存储引擎为InnoDB，今天就来仪器研究InnoDB原理。
1.表的数据存放到了哪里
InnoDB不同类型的⻚简介
InnoDB是将表中的数据存储到磁盘中，所以关闭服务器数据不会丢失。而真正发生数据处理是在内存中完成的，这样内存与磁盘的数据交互，实现了对数据的读写，而读写磁盘过程相比内存读写很慢，InnoDB采取的方式为：
将数据划分为页，以页为作为交互的数据单元，基本大小为16KB。
InnoDB为了不同的⽬的⽽设计了 许多种不同类型的⻚，⽐如存放表空间头部信息的⻚，存放Insert Buffer信息的⻚，存放INODE信息的⻚，存放undo⽇志信息的⻚等等等等。
Page Directory页目录
了解到每条记录在页中按照主键从小到大的顺序串联为单链表，那么如何根据主键在页中查找某个记录。
SELECT * FROM record_compact WHERE C1=3;
最笨的办法：从Infimum记录（最⼩记录）开始，沿着链表⼀直往 后找，这种暴力查找当然是不可取的，为此InnoDB设计一种目录索引。制作过程如下：
步骤一：将所有的记录（最大最小记录， 不包括已标记删除的记录）分组
步骤二：将每组中的最后一条记录（也就是组内最大的记录那条）的头信息的n_owned属性表示为改组拥有的记录条数
步骤三：将每组的最后一条记录的地址偏移量（槽）单独拿出来放在靠近页尾部的地方即page_directory页目录。所以这个⻚⾯⽬录就是由槽组成的。
所以在⼀个数据⻚中查找指定主键值的记录的过程分为两步： 1. 通过⼆分法确定该记录所在的槽，并找到该槽中主键值最⼩的 那条记录。
2. 通过记录的next_record属性遍历该槽所在的组中的各个记录。
2.以什么方式存储
我们平时以记录为单元向表中插入数据，这些记录在磁盘上的存储方式称为行格式或者记录格式。目前设计了4中行格式：Compact、Redundant、 dynamic、Compressed
行格式的语法：
CREATE TABLE 表名 （列信息） ROW_FOMAT=行格式名称
ALTER TABLE 表名 ROW_FORMAT=行格式名称
------------------------------------------------------------------------------------
例如：->USE dabao；
->CREATE TABLE record_format(c1 VARCHAR(10),c2 VARCHAR(10),c3 CHAR(10),c4 VARCHAR(10) NOT NULL) CHARSET=ascii ROW_FORMAT=COMPACT;
INSERT INTO record_format(c1,c2,c3,c4)VALUES('AAA','BBBB','CCCC','DDDD'),('EEE','DDDD','DADA'NULL);
然后我们就开始解开每个行格式下的存储方式的神秘面纱。
COMPACT行格式
compact分为记录的额外信息和记录的真实数据。
额外信息：服务器为了描述这个记录而不得不额外添加一些信息，分为3类，
额外信息
（1）变长字段长度列表
MySQL支持一些变长的数据类型，变长字段占用的存储空间分为两部分：真正的数据内容和占用的字节数。
把真正的数据内容占据的字节长度放在记录的开头，从而形成一个变字长的字段长度列表，各字段占用的字节数按照列的顺序逆序存放。根据每条记录中的列数据中的字符串大小，来判断具体使用1字节还是2个字节存储真实数据，InnoDB有自己的一套规则。Ｍ：选用的字符集类型中一个字符所占用的大小；Ｗ：变长类型的最大存储字符数；Ｌ：实际存储的字节大小。
ｉｆ Ｗ＊Ｍ＜２５５ 则采用１个字符存储真正字符串占用的字节数
ｅｌｓｅ ｉｆ Ｗ＊Ｍ＞２５５ ＆＆ Ｌ＜１２７ 则采用１个字符存储真正字符串占用的字节数 ｅｌｓｅ 则采用２个字符存储真正字符串占用的字节数
变长字段长度列表只存储值为非ＮＵＬＬ，
（2）NULL值 列表
不让把所有的ｎｕｌｌ值都存储到真实数据中，所以ｃｏｍｐａｃｔ列格式把ｎｕｌｌ的列集中管理，存储到ｎｕｌｌ值列表中，处理过程：
１．统计表中允许存储null的列表，如果表中没有可以null的列，则null值列表也不存在。否则每个允许null值的列占用一个位，并且逆序排列，二进制值为1时，该列的值为null。否则不为空。
2.MySQL中规定所有的null列必须存储在整个字节的位中，位数不足则最高位补零。
（3）记录头信息
5个固定字节数。记录当前记录条数，当前堆位置，下一条记录位置等信息。
头信息
(1) User Record
（2）记录头信息的秘密
1.delete_mask这个属性表示当前记录是否被删除 占用一个位 值为1则已经删除。需要注意的是，这里的删除记录，并不是立即从磁盘中清除，是因为如果每次记录删除立即磁盘清除的话，就需要将其他记录在磁盘上重新排序需要消耗性能，所以只是打个标记，将所有的删除记录组成一个垃圾链表，标记的垃圾链表的空间则变为可重用空间，新来的记录就会覆盖标记删除的记录。
！！！删除记录位为1时与该记录假如垃圾链表其实是两个阶段。跟事务的删除操作有关。
2.min_rec_mask B+树的每层非叶子节点的最小记录都会添加该标记。索引的时候会用到。
3.n_owned
4.heap_no 表示当前记录在页中的位置，有趣的是InnoDB会在每页上默认添加最大最小伪纪录作为补充称一条完整记录。
图中可以看出 最⼩记录和最⼤记录的heap_no值分 别是0和1，也就是说它们的位置最靠前。
5.record_type 表示当前记录类型，0：普通记录；1：非叶子节点记录，索引 2：最小记录；3 最大记录
6.next_record 表示从当前记录的真实数据到下⼀条记录的真实数据的地址偏移量.下⼀条记录指得并不是按照我们插⼊顺序的下⼀条记录，⽽是按照主键值由⼩到⼤的顺序的下⼀条记录.
删除一个记录时
真实数据
MySQL中除了存储c1,c2,c3,c4用户自定义列数据外，MySQL会自动为每条记录添加三个隐藏列：ROW_id(主键，唯一标识一条记录，6个字节)、 transaction_id（ 事务ID 6个字节 ）ROLL_id（回滚指针，7个字节）
对于第2条记录中c3和c4列的值都为NULL，它们被存储在了前边的NULL值列表处，在记录的真实数据处就不再冗余存储，从⽽节省存储空间。
最终的compact列格式：
注意第1条记录中c3列的值，它是CHAR(10)类型的，它实际 存储的字符串是：'cc'，⽽ascii字符集中的字节表示 是'0x6363'，虽然表示这个字符串只占⽤了2个字节，但整 个c3列仍然占⽤了10个字节的空间，除真实数据以外的8个字 节的统统都⽤空格字符填充，空格字符在ascii字符集的表示 就是0x20。
如果想要c3列也变为可变字段长度，则将定长字符集改为可变字符集。
ALTER TABLE record_format MODIFY COLUMN c3 CHAR(10) CHARACTER SET =utf8;
⾏溢出数据
数据溢出问题：
对于Compact和Reduntant⾏格式来说，如果 某⼀列中的数据⾮常多的话，在本记录的真实数据处只会存储该列的前768个字节的数据和20个字节存储指向这些⻚的地址，然后把剩下的数据存放到其他⻚中，这个过程也叫做⾏溢出，存储超出768字节的那些⻚⾯也被称为溢出⻚。
不只是 VARCHAR(M) 类型的列，其他的 TEXT、BLOB 类型的列在存储数据⾮常多的时候也会发⽣⾏溢出。
⾏溢出的临界点
MySQL中规定⼀个⻚中⾄少存放两⾏记录，溢出条件：
（1）每个⻚除了存放我们的记录以外，也需要存储⼀些额外的信 息，乱七⼋糟的额外信息加起来需要136个字节的空间。
（2）每个记录需要的额外信息是27字节。
假设⼀个列中存储的数据字节数为n，那么发⽣⾏溢出现象时需要满
⾜这个式⼦：136 + 2×(27 + n) > 16384（页大小16K） 求解这个式⼦得出的解是：n > 8098。
Dynamic和Compressed⾏格式
MySQL版本是5.7，它的默认⾏格式就是Dynamic，这俩⾏格式和Compact⾏格式挺像，只不过在处理⾏溢出数据时有点⼉分歧，它们不会在记录的真实数据处存储字段真实数据的前768个字节，⽽是把所有的字节都存储到其他⻚⾯中，只在记录的真实数据处存储其他⻚⾯的地址。
Compressed⾏格式和Dynamic不同的⼀点是，Compressed⾏格 式会采⽤压缩算法对⻚⾯进⾏压缩，以节省空间。
小结：
1. ⻚是MySQL中磁盘和内存交互的基本单位，也是MySQL是管理存储空间的基本单位。
2. 指定和修改⾏格式的语法如下：
CREATE TABLE 表名 (列的信息) ROW_FORMAT=⾏格式名称
ALTER TABLE 表名 ROW_FORMAT=⾏格式名称
3. InnoDB⽬前定义了4种⾏格式
* COMPACT⾏格式
*REDUNDANT
*DYNAMIC
* COMPRESSED
总结
1. InnoDB为了不同的⽬的⽽设计了不同类型的⻚，我们把⽤于存放记录的⻚叫做数据⻚。
2. ⼀个数据⻚可以被⼤致划分为7个部分，分别是
File Header，表示⻚的⼀些通⽤信息，占固定的38字节。
Page Header，表示数据⻚专有的⼀些信息，占固定的56个字节。
Infimum + Supremum，两个虚拟的伪记录，分别表示⻚中的最⼩和最⼤记录，占固定的26个字节。
User Records：真实存储我们插⼊的记录的部分，⼤⼩不固定。
Free Space：⻚中尚未使⽤的部分，⼤⼩不确定。
Page Directory：⻚中的某些记录相对位置，也就是各个槽在⻚⾯中的地址偏移量，⼤⼩不固定，插⼊的记录越多，这个部分占⽤的空间越多。
File Trailer：⽤于检验⻚是否完整的部分，占⽤固定的8个字节。
3. 每个记录的头信息中都有⼀个next_record属性，从⽽使⻚中的所有记录串联成⼀个单链表
4. InnoDB会为把⻚中的记录划分为若⼲个组，每个组的最后⼀个记录的地址偏移量作为⼀个槽，存放在Page Directory中，所以在⼀个⻚中根据主键查找记录是⾮常快的，分为两步：
通过⼆分法确定该记录所在的槽。
通过记录的next_record属性遍历该槽所在的组中的各个记录。
5. 每个数据⻚的File Header部分都有上⼀个和下⼀个⻚的编号，所以所有的数据⻚会组成⼀个双链表。
6. 为保证从内存中同步到磁盘的⻚的完整性，在⻚的⾸部和尾部都会存储⻚中数据的校验和和⻚⾯最后修改时对应的LSN值，如果⾸部和尾部的校验和和LSN值校验不成功的话，就说明同步过程出现了问题。