存储引擎的作用就是内存和磁盘打交道，负责将数据在他两之间传输，为了提高传输效率，提出了“页”的概念，也就是在一般情况下，为了减少io次数，一次最少从磁盘中读取16KB的内容到内存中，一次最少把内存中的16KB内容刷新到磁盘中。
页：将数据划分为若干个页，以页作为磁盘和内存之间交互的基本单位，中页的大小一般为 16 KB。
# 行格式
行格式：记录在磁盘上的存放方式称为行格式。
四种行格式： 、 、 和 行格式。
# 指定行格式命令
REATE TABLE 表名 (列的信息) ROW_FORMAT=行格式名称
ALTER TABLE 表名 ROW_FORMAT=行格式名称
mysql> CREATE TABLE record_format_demo (
-> c1 VARCHAR(10),
-> c2 VARCHAR(10) NOT NULL,
-> c3 CHAR(10),
-> c4 VARCHAR(10)
-> ) CHARSET=ascii ROW_FORMAT=COMPACT;
Query OK, 0 rows affected (0.03 sec)
# 介绍的行格式
可以把记录分为记录额外信息，记录真实数据
# 记录额外信息边长字段长度列表：记录可变长度字段的真实数据占用的字节数 注意：变长字段长度列表中只存储值为 非NULL 的列内容占用的长度，值为 NULL 的列的长度是不储存的null值列表：值为 NULL 的列统一管理起来，存储到 NULL 值列表中记录头信息：固定的 5 个字节组成，存放记录的描述信息
# 真实数据
除了存放真实数据外，还会添加隐藏列，具体如下：
列名
是否必须
占用空间
描述
否
6 字节
行ID，唯一标识一条记录
是
6 字节
事务ID
是
7 字节
回滚指针
注意：实际上这几个列的真正名称其实是：、、，我们为了美观才写成了、和。
# char(M)的存储格式
对于 CHAR(M) 类型的列来说，当列采用的是定长字符集时，该列占用的字节数不会被加到变长字段长度列表，而如果采用变长字符集时，该列占用的字节数也会被加到变长字段长度列表
# 表的行格式采用实验
create table record_test_1 (
id bigint,
score double,
name char(4),
content varchar(8),
extra varchar(16)
)row_format=compact;
INSERT INTO `record_test_1`(`id`, `score`, `name`, `content`, `extra`) VALUES (1, 78.5, 'hash', 'wodetian', 'nidetiantadetian');
INSERT INTO `record_test_1`(`id`, `score`, `name`, `content`, `extra`) VALUES (65536, 17983.9812, 'zhx', 'shin', 'nosuke');
INSERT INTO `record_test_1`(`id`, `score`, `name`, `content`, `extra`) VALUES (NULL, -669.996, 'aa', NULL, NULL);
INSERT INTO `record_test_1`(`id`, `score`, `name`, `content`, `extra`) VALUES (2048, NULL, NULL, 'c', 'jun');
目前表结构
+
| id | score | name | content | extra |
+
| 1 | 78.5 | hash | wodetian | nidetiantadetian |
| 65536 | 17983.9812 | zhx | shin | nosuke |
| NULL | -669.996 | aa | NULL | NULL |
| 2048 | NULL | NULL | c | jun |
+
下 到C:\MySQLMySQL 5.7Datatest下找到文件.ibd，使用++ 16进制打开（在++找到插件->HEX–> view in HEX,如果没有就安装一个）
我们先来看第一条记录的,extra字段，字段长度分别为8和16，字符类型都是可变的，所以这两个字段是会被存放在变长字段长度列表,
又因为存放时的顺序是逆序的，所以应该是 10 08
# 行格式
没太理解，暂不记录
##行溢出数据
# (M)最多能存储的数据
存储一个 (M) 类型的列，其实需要占用3部分存储空间：
真实数据真实数据占用字节的长度NULL 值标识，如果该列有 NOT NULL 属性则可以没有这部分存储空间
首先前提是(M) 类型的列最多可以占用 65535 个字节！
现在假设列的字符集是ascii 字符集(一个字符代表一个字节)，表只有一个列
如果列有not null则不需要花一个字节空间存null值，真实数据的长度可能占用2个字节，即可以最大有65533个字节来存储真实数据，则可以存65533个字符如果列没有not null则需要花一个字节空间存null值，且真实数据的长度可能占用2个字节，即可以最大有65532个字节来存储真实数据，则可以存65532个字符
但是，如果字符集不是ascii 字符集呢？是utf8呢？gbk呢？
其实前面算的最大字节数是不用变得，因为字符集的改变，一个字符最大占用字节数量变了。
比如字符集是utf8的话，一个字符最大使用3个字节，所以上面的②情况，最大存储字符数65532/3=21844
上述所言在列的值允许为NULL的情况下，gbk字符集下M的最大取值就是32766，utf8字符集下M的最大取值就是21844，这都是在表中只有一个字段的情况下说的，一定要记住一个行中的所有列（不包括隐藏列和记录头信息）占用的字节长度加起来不能超过65535个字节！
# 记录中的数据太多产生的溢出
在 和 行格式中，对于占用存储空间非常大的列，在 记录的真实数据 处只会存储该列的一部分数据，把剩余的数据分散存储在几个其他的页中，然后 记录的真实数据 处用20个字节存储指向这些页的地址（当然这20个字节中还包括这些分散在其他页面中的数据的占用的字节数），从而可以找到剩余数据所在的页， 如图所示：
最后需要注意的是，不只是 (M) 类型的列，其他的 TEXT、BLOB 类型的列在存储数据非常多的时候也会发生 行溢出
# 行溢出的临界点
假设一个列中存储的数据字节数为n，那么发生 行溢出 现象时需要满足这个式子：
136 + 2×(27 + n) > 16384
n > 8098
解释：136byte一页的额外信息+一行记录（27byte的记录额外信息+nbyte真实数据）*2 > 16384byte一页最大存储字节数
注释：
136：每个页除了存放我们的记录以外，也需要存储一些额外的信息，乱七八糟的额外信息加起来需要 136 个字节的空间（现在只要知道这个数字就好了），其他的空间都可以被用来存储记录。
2：一个页中至少存放两行记录。
27：每个记录需要的额外信息是 27 字节。
16384： 一页16kb =
但这只是假设一个表只有一个列的情况，有多个列的话计算公式和结果都要修改
结论：你不用关注这个临界点是什么，只要知道如果我们想一个行中存储了很大的数据时，可能发生 行溢出 的现象。
# 和行格式# 格式
MySQL 版本是 5.7 ，它的默认行格式就是 ，这俩行格式和 行格式挺像，只不过在处理 行溢出 数据时有点儿分歧，它们不会在记 录的真实数据处存储字段真实数据的前 768 个字节，而是把所有的字节都存储到其他页面中，只在记录的真实数据处存储其他页面的地址，就像这样：
# 行格式
行格式和 不同的一点是， 行格式会采用压缩算法对页面进行压缩，以节省空间。
———END———
限 时 特 惠： 本站每日持续更新海量各大内部创业教程，永久会员只需109元，全站资源免费下载 点击查看详情
站 长 微 信： nanadh666
