存储引擎是MySQL的组件，用于处理不同表类型的SQL操作。不同的存储引擎提供不同的存储机制、索引技巧、锁定水平等功能，使用不同的存储引擎，还可以获得特定的功能。

使用哪一种引擎可以灵活选择，一个数据库中多个表可以使用不同引擎以满足各种性能和实际需求，使用合适的存储引擎，将会提高整个数据库的性能。

MySQL服务器使用可插拔的存储引擎体系结构，可以从运行中的MySQL服务器加载或卸载存储引擎。

一、查看存储引擎

-- 查看支持的存储引擎SHOW ENGINES-- 查看默认存储引擎SHOW VARIABLES LIKE 'storage_engine--查看具体某一个表所使用的存储引擎，这个默认存储引擎被修改了！show create table tablename--准确查看某个数据库中的某一表所使用的存储引擎show table status like 'tablename'show table status from database where name="tablename"

二、设置存储引擎

-- 建表时指定存储引擎。默认的就是INNODB，不需要设置CREATE TABLE t1 (i INT) ENGINE = INNODB;CREATE TABLE t2 (i INT) ENGINE = CSV;CREATE TABLE t3 (i INT) ENGINE = MEMORY;-- 修改存储引擎ALTER TABLE t ENGINE = InnoDB;-- 修改默认存储引擎，也可以在配置文件my.cnf中修改默认引擎SET default_storage_engine=NDBCLUSTER;

默认情况下，每当CREATE TABLE或ALTER TABLE不能使用默认存储引擎时，都会生成一个警告。为了防止在所需的引擎不可用时出现令人困惑的意外行为，可以启用NO_ENGINE_SUBSTITUTION SQL模式。如果所需的引擎不可用，则此设置将产生错误而不是警告，并且不会创建或更改表

三、常用存储引擎

1. InnoDB

InnoDB是MySQL5.7 默认的存储引擎，主要特性有

InnoDB存储引擎维护自己的缓冲池，在访问数据时将表和索引数据缓存在主内存中
支持事务
支持外键
B-Tree索引
不支持集群
聚簇索引
行锁
支持地理位置的数据类型和索引

2. MyISAM

每个MyISAM表存储在磁盘上的三个文件中。这些文件的名称以表名开头，并有一个扩展名来指示文件类型。

.frm文件存储表的格式。 .MYD (MYData) 文件存储表的数据。 .MYI (MYIndex) 文件存储索引。

MyISAM表具有以下特征

每个MyISAM表最大索引数是64，这可以通过重新编译来改变。每个索引最大的列数是16
每个MyISAM表都支持一个AUTO_INCREMENT的内部列。当执行INSERT或者UPDATE操作的时候，MyISAM自动更新这个列，这使得AUTO_INCREMENT列更快。
当把删除和更新及插入操作混合使用的时候，动态尺寸的行产生更少碎片。这要通过合并相邻被删除的块，若下一个块被删除，就扩展到下一块自动完成
MyISAM支持并发插入
可以将数据文件和索引文件放在不同物理设备上的不同目录中，以更快地使用数据目录和索引目录表选项来创建表
BLOB和TEXT列可以被索引
NULL被允许在索引的列中，这个值占每个键的0~1个字节
每个字符列可以有不同的字符集
MyISAM 表使用 B-tree 索引
MyISAM表的行最大限制为 (232)2 (1.844E+19)
大文件(达到63位文件长度)在支持大文件的文件系统和操作系统上被支持
键的最大长度为1000字节，这也可以通过重新编译来改变，对于键长度超过250字节的情况，一个超过1024字节的键将被用上
VARCHAR支持固定或动态记录长度
表中VARCHAR和CHAR列的长度总和有可能达到64KB
任意长度的唯一约束
All data values are stored with the low byte first. This makes the data machine and operating system independent.
All numeric key values are stored with the high byte first to permit better index compression

todo：最后两条没搞懂啥意思

四、存储引擎对比

五、数据的存储

在整个数据库体系结构中，我们可以使用不同的存储引擎来存储数据，而绝大多数存储引擎都以二进制的形式存储数据；这一节会介绍 InnoDB 中对数据是如何存储的。

在 InnoDB 存储引擎中，所有的数据都被逻辑地存放在表空间中，表空间(tablespace)是存储引擎中最高的存储逻辑单位，在表空间的下面又包括段(segment)、区(extent)、页(page)

同一个数据库实例的所有表空间都有相同的页大小；默认情况下，表空间中的页大小都为 16KB，当然也可以通过改变 innodb_page_size 选项对默认大小进行修改，需要注意的是不同的页大小最终也会导致区大小的不同

1. 如何存储表

MySQL 使用 InnoDB 存储表时，会将表的定义和数据索引等信息分开存储，其中前者存储在 .frm 文件中，后者存储在 .ibd 文件中，这一节就会对这两种不同的文件分别进行介绍。

①. .frm 文件

无论在 MySQL 中选择了哪个存储引擎，所有的 MySQL 表都会在硬盘上创建一个 .frm 文件用来描述表的格式或者说定义；.frm 文件的格式在不同的平台上都是相同的。

`CREATE TABLE test_frm(``  ``column1 CHAR(5),``  ``column2 INTEGER``);`

当我们使用上面的代码创建表时，会在磁盘上的 datadir 文件夹中生成一个 test_frm.frm 的文件，这个文件中就包含了表结构相关的信息：

②. .ibd 文件

InnoDB 中用于存储数据的文件总共有两个部分，一是系统表空间文件，包括 ibdata1、ibdata2 等文件，其中存储了 InnoDB 系统信息和用户数据库表数据和索引，是所有表公用的。

当打开 innodb_file_per_table 选项时，.ibd 文件就是每一个表独有的表空间，文件存储了当前表的数据和相关的索引数据。

2. 如何存储记录

与现有的大多数存储引擎一样，InnoDB 使用页作为磁盘管理的最小单位；数据在 InnoDB 存储引擎中都是按行存储的，每个 16KB 大小的页中可以存放 2-7992 行的记录。(至少是2条记录，最多是7992条记录)

当 InnoDB 存储数据时，它可以使用不同的行格式进行存储；MySQL 5.7 版本支持以下格式的行存储方式：

Antelope 是 InnoDB 最开始支持的文件格式，它包含两种行格式 Compact 和 Redundant，它最开始并没有名字；Antelope 的名字是在新的文件格式 Barracuda 出现后才起的，Barracuda 的出现引入了两种新的行格式 Compressed 和 Dynamic；InnoDB 对于文件格式都会向前兼容，而官方文档中也对之后会出现的新文件格式预先定义好了名字：Cheetah、Dragon、Elk 等等。

两种行记录格式 Compact 和 Redundant 在磁盘上按照以下方式存储：

Compact 和 Redundant 格式最大的不同就是记录格式的第一个部分；在 Compact 中，行记录的第一部分倒序存放了一行数据中列的长度(Length)，而 Redundant 中存的是每一列的偏移量(Offset)，从总体上上看，Compact 行记录格式相比 Redundant 格式能够减少 20% 的存储空间。

3. 行溢出数据

当 InnoDB 使用 Compact 或者 Redundant 格式存储极长的 VARCHAR 或者 BLOB 这类大对象时，我们并不会直接将所有的内容都存放在数据页节点中，而是将行数据中的前 768 个字节存储在数据页中，后面会通过偏移量指向溢出页。

但是当我们使用新的行记录格式 Compressed 或者 Dynamic 时都只会在行记录中保存 20 个字节的指针，实际的数据都会存放在溢出页面中。

当然在实际存储中，可能会对不同长度的 TEXT 和 BLOB 列进行优化，不过这就不是本文关注的重点了。

4. 数据页结构

页是 InnoDB 存储引擎管理数据的最小磁盘单位，而 B-Tree 节点就是实际存放表中数据的页面，我们在这里将要介绍页是如何组织和存储记录的；首先，一个 InnoDB 页有以下七个部分：

每一个页中包含了两对 header/trailer：内部的 Page Header/Page Directory 关心的是页的状态信息，而 Fil Header/Fil Trailer 关心的是记录页的头信息。

在页的头部和尾部之间就是用户记录和空闲空间了，每一个数据页中都包含 Infimum 和 Supremum 这两个虚拟的记录(可以理解为占位符)，Infimum 记录是比该页中任何主键值都要小的值，Supremum 是该页中的最大值：

User Records 就是整个页面中真正用于存放行记录的部分，而 Free Space 就是空余空间了，它是一个链表的数据结构，为了保证插入和删除的效率，整个页面并不会按照主键顺序对所有记录进行排序，它会自动从左侧向右寻找空白节点进行插入，行记录在物理存储上并不是按照顺序的，它们之间的顺序是由 next_record 这一指针控制的。

B+ 树在查找对应的记录时，并不会直接从树中找出对应的行记录，它只能获取记录所在的页，将整个页加载到内存中，再通过 Page Directory 中存储的稀疏索引和 n_owned、next_record 属性取出对应的记录，不过因为这一操作是在内存中进行的，所以通常会忽略这部分查找的耗时。

InnoDB 存储引擎中对数据的存储是一个非常复杂的话题，这一节中也只是对表、行记录以及页面的存储进行一定的分析和介绍，虽然作者相信这部分知识对于大部分开发者已经足够了，但是想要真正消化这部分内容还需要很多的努力和实践。