【Mysql】Mysql中的B+树索引（六）

概述

从上一章节我们了解到InnoDB 的数据页是由7个部分组成，然后各个数据页之间可以组成一个双向链表 ，而每个数据页中的记录会按照主键值从小到大的顺序组成一个单向链表 ，每个数据页都会为存储在它里边儿的记录生成一个页目录 ，在通过主键查找某条记录的时候可以在页目录中使用二分法快速定位到对应的槽，然后再遍历该槽对应分组中的记录即可快速找到指定的记录。页和记录的关系示意图如下：

不同页之间在物理结构上不一定就相连，只要通过双向链表相关联即可。

没有索引的查找

首先我们看看在没有设置索引的情况下是怎么查找记录的。方便理解，我们先以搜索条件为对某个列精确匹配的情况，所谓精确匹配，就是搜索条件中用等于 = 连接起的表达式，比如：
SELECT [列名列表] FROM 表名 WHERE 列名 = xxx;

在一个页中的查找

假设目前表中的记录比较少，所有的记录都可以被存放到一个页（16k）中，在查找记录的时候可以根据搜索条件的不同分为两种情况：

• 以主键为搜索条件
  可以在页目录中使用二分法快速定位到对应的槽，然后再遍历该槽对应分组中的记录即可快速找到指定的记录。
• 以其他列作为搜索条件
  对非主键列的查找的过程就没有这么容易了，因为在数据页中并没有对非主键列建立所谓的页目录 （可以理解为某页的目录，页目录中存放的是槽，而槽其实就是地址偏移量），所以我们无法通过二分法快速定位相应的槽 。这种情况下只能从最小记录开始依次遍历单链表中的每条记录，然后对比每条记录是不是符合搜索条件。很显然，这种查找的效率是非常低的。

在多页中查找

大部分情况下我们表中存放的记录都是非常多的，需要好多的数据页来存储这些记录。在很多页中找记录的话可以分为两个步骤：
1 . 定位到记录所在的页。
2 . 从所在的页内中查找相应的记录。
在没有索引的情况下，不论是根据主键列或者其他列的值进行查找，由于我们并不能快速的定位到记录所在的页，所以只能从第一个页沿着双向链表一直往下找，在每一个页中就跟上面单页中的查找方法一样。因为要遍历所有的数据页，所以这种方式是非常耗时的，如果一个表数据很多，使用这种方式去查找记录等待的时间可能就相当的久了， 为了解决这个问题，就设计出了索引。

索引

方便测试，先建一个表：

mysql> create table index_demo(c1 int,c2 int,c3 char(1), primary key(c1)) row_format=compact;
Query OK, 0 rows affected (0.13 sec)

新建的 index_demo 表中有，c1、c2为 INT 类型的列，c3为 CHAR(1) 类型的列，并且设置c1 列为主键列，使用 Compact 行格式来实际存储记录的。简化的 index_demo 表的行格式示意图如下，其他字段被省略：

示意图里展示记录的这几个部分说明：

• record_type ：记录头信息中的属性，表示记录的类型，0 表示普通记录、2 表示最小记录、3 表示最大记录、 1其实就是索引
• next_record ：记录头信息中的属性，表示下一条地址相对于本条记录的地址偏移量，方便理解，我们使用箭头来表明下一条记录是谁。
• 各个列的值 ：这里只记录在 index_demo 表中的三个列，分别是 c1 、 c2 和 c3 。
• 其他信息 ：除了上述3种信息以外的所有信息，包括其他隐藏列的值以及记录的额外信息

为了方便理解，把记录示意图竖放起来更直观，并省略掉一些无关字段，然后把一些记录放到页里边的示意图就如下：

一个简单的索引方案

实际使用中，我们在根据某个搜索条件查找一些记录时为什么要遍历所有的数据页呢？因为各个页中的记录并没有规律，我们并不知道我们的搜索条件匹配哪些页中的记录，所以不得不依次遍历所有的数据页。所以如果我们想快速的定位到需要查找的记录在哪些数据页中该咋办？之前为了快速定位一条记录在某数据页中的位置建立了页目录，我们也可以类似为所有的数据页建立一个目录，建这个目录必须遵循以下原则就是：下一个数据页中用户记录的主键值必须大于上一个页中用户记录的主键值。（注意是两种目录，数据页目录和页目录，有点绕）
为方便说明，我们做一个假设：假设我们的每个数据页最多能存放3条记录（但是实际上一个数据页一般是16K，可以存放很多记录）。有了这个假设之后我们向 index_demo 表插入3条记录：

mysql>  insert into index_demo VALUES(1, 4, 'u'), (3, 9, 'd'), (5, 3, 'y');
Query OK, 3 rows affected (0.02 sec)
Records: 3  Duplicates: 0  Warnings: 0

那么这些记录已经按照主键值的大小串联成一个单向链表了，如图所示：

从图中可以看出来， index_demo 表中的3条记录都被插入到了编号为 10 的数据页中了。此时我们再来插入
一条记录：

mysql> insert into index_demo values(4, 4, 'a');
Query OK, 1 row affected (0.02 sec)

因为页10最多只能放3条记录（假设过的），所以我们需要再分配一个新页：

可以看到新分配的页号是 28，并不是11 ，原因是因为新分配的数据页编号并不一定就是连续的，也就是说我们使用的这些页在存储空间里可能并不相邻。它们只是通过维护着上一个页和下一个页的编号而建立了链表关系。另外，页10中用户记录最大的主键值是5，而页28中有一条记录的主键值是4，因为5>4，所以这就不符合下一个数据页中用户记录的主键值必须大于上一个页中用户记录的主键值的要求，所以在插入主键值为4的记录的时候需要伴随着一次记录移动，也就是把主键值为5的记录移动到 页28中，然后再把主键值为4的记录插入到 页10 中，这个过程的示意图如下：

这个过程表明了在对页中的记录进行增删改操作的过程中，我们需要通过一些诸如记录移动的操作来始终保证这个状态一直成立**（伴随着性能消耗）**：下一个数据页中用户记录的主键值必须大于上一个页中用户记录的主键值。这个过程我们也可以称为页分裂 。

• 给所有的页建立一个目录项。
  由于数据页的编号可能并不是连续的，所以在向 index_demo 表中插入许多条记录后，可能变成如下所示：
  

因为这些16KB的页在物理存储上可能并不挨着，所以如果想从这么多页中根据主键值快速定位某些记录所在的页，我们需要给它们做个目录，每个页对应一个目录项，每个目录项包括下边两个部分：

• 页的用户记录中最小的主键值，我们用 key 来表示
• 页号，我们用 page_no 表示。
  所以我们为上边几个页做好的目录就像这样子

以页9为例，它对应目录项3 ，这个目录项中包含着该页的页号9以及该页中用户记录的最小主键值 12 。我们只需要把几个目录项在物理存储器上连续存储，比如把他们放到一个数组里，就可以实现根据主键值快速查找某条记录的功能了。比方说我们想找主键值为 50的记录，具体查找过程分两步：

• 先从目录项中根据二分法快速确定出主键值为 50 的记录在目录项3中（因为 12 < 50 < 209 ），它对应的页是页9 。
• 再根据页目录数据查找方式二分法去页9 中查找具体的记录。
  至此，针对数据页做的简易目录就完成了。其实这个目录就是我们常说的索引（数据页目录） 。

InnoDB中的索引方案

上面这个简易的索引方案，我们是假设所有目录项都可以在物理存储器上连续存储，根据主键值进行查找时可以使用二分法快速定位具体的目录项，但是存在几个问题：

• InnoDB 是使用页来作为管理存储空间的基本单位，也就是最多能保证 16KB 的连续存储空间，而随着表中记录数量的增多，需要非常大的连续的存储空间才能把所有的目录项都放下，保证连续的页就是不现实的。
• 如果表中的数据经常发生变化，假设我们把页9中的所有记录都删除了，页 9 就没有存在的必要了，那意味着目录项3也就不需要了，这时目录项 3 后的目录项都需要向前移动一下，这种牵一发而动全身的设计影响太大。

所以，InnoDB采用了一种可以灵活管理所有目录项的方式。将目录项中的两个列是主键和页号组成一个新的表，就可以复用之前存储用户记录的数据页来存储目录项，为了和用户记录做一下区分，我们把这些用来表示目录项的记录称为目录项记录 。InnoDB 中通过record_type 属性来区分某条记录是普通的用户记录还是目录项记录。属性的各取值代表的意思如下：
0 ：普通的用户记录
1 ：目录项记录
2 ：最小记录
3 ：最大记录

从上图可以看出，我们新分配了一个编号为30的页来专门存储目录项记录 。注意目录项记录和普通的用户记录的区别：

• 目录项记录 的 record_type 值是1，而普通用户记录的 record_type 值是0。
• 目录项记录只有主键值和页的编号两个列，而普通的用户记录的列是用户自己定义的，包含用户定义列 和 InnoDB 添加的隐藏列。
• 还有 min_rec_mask 的属性，只有在存储目录项记录的页中的主键值最小的目录项记录 的min_rec_mask 值为 1 ，其他记录的 min_rec_mask 值都是 0 。

除此之外，这两者就没啥其他差别了，它们用的是一样的数据页（页面类型都是 0x45BF ，这个属性在 File Header 中），页的组成结构也是一样一样的（就是我们前边介绍过的7个部分），都会为主键值生成 Page Directory （页目录），从而在按照主键值进行查找时可以使用二分法来加快查询速度。现在以查找主键为 20 的记录为例，根据某个主键值去查找记录的步骤就可以大致拆分成下边两步：
1 . 先到存储 目录项记录的页，也就是在页30中通过二分法快速定位到对应目录项，因为 12 < 20 < 209 ，所以定位到对应的记录所在的页就是9 。
2 . 再到存储用户记录（叶子节点）的 页9 中根据二分法快速定位到主键值为 20的用户记录。

虽然说目录项记录中只存储主键值和对应的页号，一般比用户记录需要的存储空间小，但是一个页还是只有16KB，能存放的目录项记录也是有限的，那如果表中的数据太多，以至于一个数据页不足以存放所有的目录项记录 ，该咋办呢？

当然是增加存储目录项记的页，为了更好的理解新分配一个目录项记录页的过程，我们假设一个存储目录项记录的页最多只能存放4条 目录项记录 （请注意是假设，实际情况下16K可以存放很多条），所以如果此时我们再向上图中插入一条主键值为 320 的用户记录的话，那就需要分配一个新的存储目录项记录的页：

从图中可以看出，我们插入了一条主键值为 320 的用户记录之后需要两个新的数据页：为存储该用户记录而新生成了页31 。
因为原先存储目录项记录的页3 的容量已满（我们前边假设只能存储4条目录项记录 ），所以需要一个新的页32来存放页31对应的目录项。
现在因为存储目录项记录 的页不止一个，所以如果我们想根据主键值查找一条用户记录大致需要3个步骤，以查找主键值为220的记录为例：
1 . 确定目录项记录页
我们现在的存储目录项记录的页有两个，页30和页32 ，又因为页30 表示的目录项的主键值的范围是[1, 320) ，页32表示的目录项的主键值不小于320，所以主键值为220的记录对应的目录项记录在页30中（1<20<320）。
2 .通过目录项记录页确定用户记录真实所在的页（二分法）。
3 . 在真实存储用户记录的页中定位到具体的记录。（二分法）

那么问题来了，在这个查询步骤的第1步中我们需要定位存储目录项记录的页，但是这些页在存储空间中也可能不相邻，如果我们表中的数据非常多则会产生很多存储 目录项记录的页，那我们怎么根据主键值快速定位一个存储目录项记录的页呢？遍历是不可能的，方法就是为这些存储 目录项记录 的页再生成一个更高级的目录，就像是一个多级目录一样，大目录里嵌套小目录，小目录里才是实际的数据，所以现在各个页的示意图就是这样子：

如图，我们生成了一个存储更高级目录项的 页33 ，这个页中的两条记录分别代表页30和页32 ，如果用户记录的主键值在 [1, 320) 之间，则到页30中查找更详细的目录项记录 ，如果主键值不小于320的话，就到 页32中查找更详细的目录项记录 。随着表中记录的增加，这个目录的层级会继续增加，如果简化一下，那么我们可以用下边这个图来描述它：

这看起来有点像一颗倒过来的树，上头是树根，下头是树叶！其实这是一种组织数据的形式，或者说是一种数据结构，这就是我们常说的 B+ 树。

不论是存放用户记录的数据页，还是存放目录项记录的数据页，我们都把它们存放到 B+ 树这个数据结构中了，所以我们也称这些数据页为节点 。从图中可以看出来，我们的实际用户记录其实都存放在B+树的最底层的节点上，这些节点也被称为叶子节点 或叶节点 ，其余用来存放目录项的节点称为非叶子节点或者内节点 （B+数的上层节点），其中 B+ 树最上边的那个节点也称为根节点 （注意根节点有且只有一页）。

从上图可以看出来，一个 B+树的节点其实可以分成好多层，InnoDB引擎规定最下边的那层，也就是我们存放用户记录的那层为第 0 层，之后依次往上加。之前的讨论我们做了一个非常极端的假设：存放用户记录的页最多存放3条记录，存放目录项记录的页最多存放4条记录。其实真实环境中一个页存放的记录数量是非常大的，假设所有存放用户记录的叶子节点代表的数据页可以存放100条用户记录，所有存放目录项记录的内节点代表的数据页可以存放1000条目录项记录（因为列数一般比用户真实记录列数少），那么：

• 如果 B+ 树只有1层，也就是只有1个用于存放用户记录的节点，最多能存放 100 条记录。
• 如果 B+ 树有2层，最多能存放 1000×100=100000 条记录。
• 如果 B+ 树有3层，最多能存放 1000×1000×100=100000000 条记录。
• 如果 B+ 树有4层，最多能存放 1000×1000×1000×100=100000000000 条记录。

然而我们实际使用中一个表的数据量不会有100000000000 条，所以一般情况下，我们用到的 B+ 树都不会超过4层，我们通过主键值去查找某条记录最多只需要做4个页面内的查找（查找3个目录项页和一个用户记录页），又因为在每个页面内有所谓的 Page Directory（页目录），所以在页面内也可以通过二分法实现快速定位记录，所以一般来说，通过索引来查找数据速度都非常快。

聚簇索引

我们上边介绍的 B+ 树本身就是一个目录，或者说本身就是一个索引。它有两个特点：
1 . 使用记录主键值的大小进行记录和页的排序，这包括三个方面的含义：

• 页内的记录是按照主键的大小顺序排成一个单向链表。
• 各个存放用户记录的页也是根据页中用户记录的主键大小顺序排成一个双向链表。
• 存放目录项记录的页分为不同的层次，在同一层次中的页也是根据页中目录项记录的主键大小顺序排成一个双向链表。
  2 . B+ 树的叶子节点存储的是完整的用户记录。
  所谓完整的用户记录，就是指这个记录中存储了所有列的值（包括隐藏列）。

我们把具有这两种特性的 B+ 树称为聚簇索引 ，所有完整的用户记录都存放在这个聚簇索引的叶子节点处。这种聚簇索引不需要我们在 MySQL 语句中显式的使用 INDEX 语句去创建（后边会介绍索引相关的语句），InnoDB 存储引擎会自动的为我们创建聚簇索引。在 InnoDB 存储引擎中， 聚簇索引就是数据的存储方式（所有的用户记录都存储在了叶子点），也就是所谓的索引即数据，数据即索引。

二级索引

上边介绍的聚簇索引只能在搜索条件是主键值时才能发挥作用（可以理解为需要创建主键索引），因为 B+ 树中的数据都是按照主键进行排序的。如果我们想以别的列作为搜索条件，就需要根据搜索条件多创建几棵 B+ 树，不同的 B+ 树中的数据采用不同的排序规则。比如说我们用 c2 列的大小作为数据页、页中记录的排序规则，再建一棵 B+ 树，效果如下图所示：

这个 B+ 树与上边介绍的聚簇索引有几处不同：

• 使用记录 c2 列的大小进行记录和页的排序，这包括三个方面的含义：
  • 页内的记录是按照 c2 列的大小顺序排成一个单向链表。
  • 各个存放用户记录的页也是根据页中记录的 c2 列大小顺序排成一个双向链表。
  • 存放目录项记录的页分为不同的层次，在同一层次中的页也是根据页中目录项记录的 c2 列大小顺序排成一个双向链表。
• B+ 树的叶子节点存储的并不是完整的用户记录，而只是 c2列+主键 这两个列的值。
• 目录项记录中不再是主键+页号的搭配，而是 c2列+页号的搭配。

所以如果我们现在想通过 c2 列的值查找某些记录的话就可以使用我们刚刚建好的这个B+树了。以查找c2列的值为4的记录为例，查找过程如下：
1 . 确定目录项记录页
根据根页面页44 ，可以快速定位到目录项记录所在的页为页42 （因为 2 < 4 < 9 ）。
2 . 通过目录项记录页确定用户记录真实所在的页。
在页42中可以快速定位到实际存储用户记录的页，但是由于c2列并没有唯一性约束，所以c2列值为4的记录可能分布在多个数据页中，又因为 2 < 4 ≤ 4 ，所以确定实际存储用户记录的页在页34和页35中。
3 . 在真实存储用户记录的页中定位到具体的记录。
到页34和页35 中定位到具体的记录。
4 . 但是这个 B+ 树的叶子节点中的记录只存储了 c2 和 c1 （也就是主键 ）两个列，所以我们必须再根据主键值去聚簇索引中再查找一遍完整的用户记录（回表过程）。

注意：我们根据这个以 c2 列大小排序的 B+ 树只能确定我们要查找记录的主键值，所以如果我们想根据 c2 列的值查找到完整的用户记录的话，仍然需要到聚簇索引中再查一遍，这个过程也被称为回表 。也就是根据 c2 列的值查询一条完整的用户记录需要使用到2棵 B+ 树。

回表操作会产生性能消耗，但是为什么还是需要呢？直接把完整的用户记录再一次放到叶子节点不就解决了么？确实如果把完整的用户记录放到叶子节点是可以不用回表 ，但是太占存储空间了。如果某个表的索引有多个，那就相当于把所有的用户记录都拷贝多遍，太浪费存储空间。因为这种按照非主键列建立的 B+ 树需要一次回表操作才可以定位到完整的用户记录，所以这种 B+ 树也被称为二级索引 （英文名 secondary index ），或者辅助索引 。由于我们使用的是 c2 列的大小作为 B+ 树的排序规则，所以我们也称这个B+树为 为c2列建立的索引。

联合索引

我们也可以同时以多个列的大小作为排序规则，也就是同时为多个列建立索引，比方说我们想让 B+ 树按照 c2和 c3 列的大小进行排序，这个包含两层含义：

• 先把各个记录和页按照 c2 列进行排序。
• 在记录的 c2 列相同的情况下，采用 c3 列进行排序

为 c2 和 c3 列建立的索引的示意图如下：

如上图所示，我们需要注意一下几点：

• 每条目录项记录都由 c2 、 c3 、页号 这三个部分组成，各条记录先按照c2列的值进行排序，如果记录的c2 列相同，则按照 c3 列的值进行排序。
• B+ 树叶子节点处的用户记录由 c2 、 c3 和主键 c1 列组成。
  注意：以c2和c3列的大小为排序规则建立的B+树称为联合索引，实质上也是一个二级索引。它的意思与分别为c2和c3列分别建立索引的表述是不同的，不同点如下：
• 建立联合索引只会建立如上图一样的1棵 B+ 树。
• 为c2和c3列分别建立索引会分别以 c2 和 c3 列的大小为排序规则建立2棵 B+ 树。

InnoDB的B+树索引的注意事项

固执的根页面

我们知道存储目录项记录的内节点，存储真实用户记录的是叶子节点。实际上 B+ 树的形成过程是动态的，如下：

• 每当为某个表创建一个 B+ 树索引（聚簇索引不是人为创建的，默认就有）的时候，都会为这个索引创建一个根节点页面。最开始表中没有数据的时候，每个 B+ 树索引对应的、根节点 中既没有用户记录，也没有目录项记录。
• 随后向表中插入用户记录时，先把用户记录存储到这个根节点中。
• 当根节点中的可用空间用完时继续插入记录，此时会将根节点中的所有记录复制到一个新分配的页，比如页a中，然后对这个新页进行页分裂的操作，得到另一个新页，比如页b 。这时新插入的记录根据键值（也就是聚簇索引中的主键值，二级索引中对应的索引列的值）的大小就会被分配到页a或者页b中，而根节点便升级为存储目录项记录的页。

注意：一个B+树索引的根节点自创建之日起，便不会再移动。只要我们对某个表建立一个索引，那么它的根节点的页号便会被记录到某个地方（系统表中），然后凡是 InnoDB 存储引擎需要用到这个索引的时候，都会从那个固定的地方取出根节点的页号，从而来访问这个索引。

内节点中目录项记录的唯一性

我们知道 B+ 树索引的内节点中目录项记录的内容是由索引列 + 页号组成，这个组成对于普通二级索引来说并不严谨，因为很可能发生重复。还拿 index_demo 表为例，假设这个表中的数据是这样的

c1	c2	c3
1	1	‘u’
3	1	‘d’
5	1	‘y’
7	1	‘a’

如果二级索引中目录项记录的内容只是索引列 +页号的搭配的话，那么为 c2 列建立索引后的 B+ 树应该入下:

如果我们想新插入一行记录，其中 c1 、 c2 、 c3 的值分别是: 9 、 1 、 ‘c’ ，那么在更新这个为 c2 列建立的二级索引对应的 B+ 树时便出现个问题：由于页3中存储的目录项记录是由 c2列 + 页号的值构成的，页3 中的两条目录项记录对应的 c2 列的值都是 1 ，而我们新插入的这条记录的 c2 列的值也是 1 ，那我们这条新插入的记录到底应该放到页4 中，还是应该放到页5 中。
为了让新插入记录能找到自己在那个页里，我们需要保证在B+树的同一层内节点的目录项记录除 页号这个字段以外是唯一的。所以对于二级索引的内节点的目录项记录的内容实际上是由三个部分构成的:

• 索引列的值
• 主键值
• 页号
  也就是我们把主键值也添加到二级索引非叶子节点中的目录项记录中，这样就可以保证 B+ 树每一层节点中组成的目录项记录是唯一的，所以我们为 c2 列建立二级索引后的示意图实际上应该是如下的:
  
  这样我们再插入记录 (9, 1, ‘c’) 时，由于页3中存储的目录项记录是由c2列 + 主键 + 页号的值构成的，可以先把新记录的 c2 列的值和 页3 中各目录项记录的 c2 列的值作比较，如果 c2 列的值相同的话，可以接着比较主键值，因为 B+ 树同一层中不同目录项记录的 c2列 + 主键的值肯定是不一样的，所以最后肯定能定位唯一的一条目录项记录，在本例中最后确定新记录应该被插入到页5 中。

一个页面最少存储2条记录

实际使用中，一个B+树只需要很少的层级就可以轻松存储数亿条记录，而且添加了索引查询速度也很快。这是因为B+树本质上就是一个大的多层级目录，每经过一个目录时都会过滤掉许多无效的子目录，直到最后访问到存储真实数据的目录。那假如一个大的目录中只存放一个子目录是个啥效果呢?那就是目录层级非常非常多（看起来就是一条直线），而且最后的那个存放真实数据的目录中只能存放一条记录。所以 InnoDB 的 一个数据页至少可以存放两条记录，这就是我们前面在记录行格式的时候强调说的结论。

MyISAM中的索引方案简单介绍

下面我们再简单介绍一下 MyISAM 存储引擎中的索引方案。在InnoDB 中索引即数据，也就是聚簇索引的那棵 B+ 树的叶子节点中已经包含所有完整的用户记录，而 MyISAM 的索引方案虽然也使用树形结构，但是却将索引和数据分开存储：

• 将表中的记录按照记录的插入顺序单独存储在一个文件中，称之为数据文件 。这个文件并不划分为若干个数据页，有多少记录都可以记录在这个文件中。我们可以通过行号而快速访问到一条记录。MyISAM 记录也需要记录头信息来存储一些额外数据，我们以上边的 index_demo 表为例，看一下这个表中的记录使用 MyISAM 作为存储引擎在存储空间中的表示：
  
  由于在插入数据的时候并没有刻意按照主键大小排序，所以我们并不能在这些数据上使用二分法进行查找。
• 使用 MyISAM 存储引擎的表会把索引信息另外存储到一个称为索引文件的另一个文件中。 MyISAM 会单独为表的主键创建一个索引，只不过在索引的叶子节点中存储的不是完整的用户记录，而是主键值 + 行号的组合。也就是先通过索引找到对应的行号，再通过行号去找对应的记录。这一点和 InnoDB 是完全不相同的，在 InnoDB 存储引擎中，我们只需要根据主键值对聚簇索引进行一次查找就能找到对应的记录，而在 MyISAM 中却需要进行一次回表操作，说明MyISAM 中建立的索引相当于全部都是二级索引。
  如果有需要的话，我们也可以对其它的列分别建立索引或者建立联合索引，原理和 InnoDB 中的索引类似，不过在叶子节点处存储的是相应的列 + 行号 。这些索引也全部都是二级索引 。

注意：MyISAM的行格式有定长记录格式(Static)、变长记录格式(Dynamic)、压缩记录格式(Compres sed)。上边的index_demo表采用定长记录格式，也就是一条记录占用存储空间的大小是固定的，这样很容易就算出某条记录在数据文件中的地址偏移量。但是变长记录格式就不行了，MyISAM会直接在索引叶子节点处存储该条记录在数据文件中的地址偏移量。通过这个可以看出，MyISAM 的回表操作是十分快速的，因为是拿着地址偏移量直接到文件中取数据的，而InnoDB是通过获取主键之后再去聚簇索引里边儿找记录，但速度还是比不上直接用地址去访问。 这里我门主要是要理解区分在InnoDB中的索引即数据，数据即索引，而MyISAM中却是索引是索引、数据是数据。

MySQL中创建和删除索引的语句

了解了索引的原理后，那么在 MySQL中索引是如何创建的呢? InnoDB 和 MyISAM 会自动为主键或者声明为 UNIQUE 的列去自动建立 B+ 树索引，但是如果我们想为其他的列建立索引就需要我们显式的去指明。我们需要按需建立合适的索引，因为每建立一个索引都会建立一棵 B+ 树，每插入一条记录都要维护各个记录、数据页的排序关系，这都是需要消耗性能和存储空间的。
我们可以在创建表的时候指定需要建立索引的单个列或者建立联合索引的多个列:
CREATE TALBE 表名 (
各种列的信息 ··· ,
[KEY|INDEX] 索引名 (需要被索引的单个列或多个列)
)
其中的 KEY 和 INDEX 是同义词，任意选用一个就可以。我们也可以在修改表结构的时候添加索引:
ALTER TABLE 表名 ADD [INDEX|KEY] 索引名 (需要被索引的单个列或多个列);
也可以在修改表结构的时候删除索引:
ALTER TABLE 表名 DROP [INDEX|KEY] 索引名;
比如我们想在创建 index_demo 表的时候就为 c2 和 c3 列添加一个 联合索引 ，可以这么写建表语句:
create table index_demo(
c1 int,
c2 int,
c3 char(1),
primary key(c1),
index idx_c2_c3 (c2, c3)
);
在这个建表语句中我们创建的索引名是 idx_c2_c3 ，这个名称可以随便起，方便后续顾名思义建议以 idx_ 为前缀，后边跟着需要建立索引的列名，多个列名之间用下划线 _ 分隔开。 如果我们想删除这个索引，可以这么写:
alter table index_demo drop index idx_c2_c3;

更多关于mysql的知识分享，请前往博客主页。编写过程中，难免出现差错，敬请指出