目录
前言
前文我们详细唠叨了InnoDB数据页的
7
个组成部分，知道了各个数据页可以组成一个
双向链表
，而每个数据页中的记录会按照主键值从小到大的顺序组成一个
单向链表，每个数据页都会为存储在它里边儿的记录生成一个
页目录
，在通过主键查找某条记录的时候可以在
页目录中使用二分法快速定位到对应的槽，然后再遍历该槽对应分组中的记录即可快速 找到指定的记录。
为什么需要索引？
搜索条件为对某个列精确匹配的情况，所谓精确匹配，就是搜索条件中用等于
=
连接起的表达式，比如这样：
SELECT [列名列表] FROM 表名 WHERE 列名 = xxx;在一个页中的查找
假设目前表中的记录比较少，所有的记录都可以被存放到一个页中，在查找记录的时候可以根据搜索条件的不同分为两种情况：
- 以主键为搜索条件
这个查找过程我们已经很熟悉了，可以在页目录
中使用二分法快速定位到对应的槽，然后再遍历该槽对应分组中的记录即可快速找到指定的记录。
- 以其他列作为搜索条件
对非主键列的查找的过程可就不这么幸运了，因为在数据页中并没有对非主键列建立所谓的页目录
，所以我们无法通过二分法快速定位相应的
槽
。这种情况下只能
从最小 记录开始依次遍历单链表中的每条记录，然后对比每条记录是不是符合搜索条件
。很显然，这种查找的效率是非常低的。
在很多页中查找
大部分情况下我们表中存放的记录都是非常多的，需要好多的数据页来存储这些记录。在很多页中查找记录的话可以分为两个步骤：
1. 定位到记录所在的页。
2. 从所在的页内中查找相应的记录。
在没有索引的情况下，不论是根据主键列或者其他列的值进行查找，
由于我们并不能快速的定位到记录所在的页，所以只能从第一个页沿着双向链表一直往下找，在每一个页中根据我们刚刚唠叨过的查找方式去查找指定的记录
。因为要遍历所有的数据页，所以这种方式显然是超级耗时的，如果一个表有一亿条记录，使用这种方式去查找记录那要 等到猴年马月才能等到查找结果。所以需要一种能高效完成搜索的方法，
索引
就要亮相登台了。
索引的设计思想
先建一个Compact
行格式的表：
mysql> CREATE TABLE index_demo( -> c1 INT,
-> c2 INT, -> c3 CHAR(1),
-> PRIMARY KEY(c1)
-> ) ROW_FORMAT = Compact;
Query OK, 0 rows affected (0.03 sec)
为了我们理解上的方便，
我们简化了一下
index_demo
表的行格式示意图：
- record_type：记录头信息的一项属性，表示记录的类型，0表示普通记录、2表示最小记录、3表示最大记录、1我们还没用过，等会再说～
- next_record：记录头信息的一项属性，表示下一条地址相对于本条记录的地址偏移量，为了方便大家理解，我们都会用箭头来表明下一条记录是谁。
- 各个列的值：这里只记录在index_demo表中的三个列，分别是c1、c2和c3。
- 其他信息：除了上述3种信息以外的所有信息，包括其他隐藏列的值以及记录的额外信息。
为了直观，将记录格式示意图的其他信息去掉并把它竖起来，把一些记录放到页里边：
一个简单的索引方案
我们在根据某个搜索条件查找一些记录时为什么要遍历所有的数据页呢？
因为各个页中的记录并没有规律，我们并不知道我们的搜索条件匹配哪些页中的记录，所以不得不
依次遍历所有的数据页
。所以如果我们想快速的定位到需要查找的记录在哪些数据页中该咋办？还记得我们为根据主键值快速定位一条记录在页中的位置而设立的
页目录么？我们也可以想办法为快速定位记录所在的数据页而建立一个别的目录：
1. 怎么分配的页号是28呀，不应该是11么？再次强调一遍，新分配的数据页编号可能并不是连续的，也就是说我们使用的这些页在存储空间里可能并不挨着。它们只 是通过维护着上一个页和下一个页的编号而建立了链表关系。
2. 因为这些16KB的页在物理存储上可能并不挨着，所以如果想从这么多页中根据主键值快速定位某些记录所在的页，我们需要给它们做个目录，每个页对应一个目录项， 每个目录项包括两个部分： 页的用户记录中最小的主键值，我们用key来表示页号，我们用page_no表示。
3.必须通过一些诸如记录移动的操作来始终保证这个状态一直成立：下一个数据页中用户记录的主键值必 须大于上一个页中用户记录的主键值。这个过程我们也可以称为页分裂。
4. 以页28为例，它对应目录项2，这个目录项中包含着该页的页号28以及该页中用户记录的最小主键值5。我们只需要把几个目录项在物理存储器上连续存储，比如把他们放 到一个数组里，就可以实现根据主键值快速查找某条记录的功能了。比方说我们想找主键值为20的记录，具体查找过程分两步：(1). 先从目录项中根据二分法快速确定出主键值为20的记录在目录项3中（因为 12 < 20 < 209），它对应的页是页9。 (2). 再根据前边说的在页中查找记录的方式去页9中定位具体的记录。
InnoDB中的索引方案
上边之所以称为一个简易的索引方案，是因为我们为了在根据主键值进行查找时使用二分法快速定位具体的目录项而假设所有目录项都可以在物理存储器上连续存储，但是这样做有几个问题：
- InnoDB是使用页来作为管理存储空间的基本单位，也就是最多能保证16KB的连续存储空间，而随着表中记录数量的增多，需要非常大的连续的存储空间才能把所有的目录项都放下，这对记录数量非常多的表是不现实的。
- 我们时常会对记录进行增删，假设我们把页28中的记录都删除了，页28也就没有存在的必要了，那意味着目录项2也就没有存在的必要了，这就需要把目录项2后的目录项都向前移动一下，这种牵一发而动全身的设计不是什么好主意～
如何优化？
所以，设计InnoDB
的大叔们需要一种可以灵活管理所有
目录项
的方式。他们灵光乍现，忽然发现这些
目录项
其实长得跟我们的用户记录差不多，只不过
目录项
中的两个列是主 键
和
页号
而已，所以他们
复用了之前存储用户记录的数据页来存储目录项，为了和用户记录做一下区分，我们把这些用来表示目录项的记录称为
目录项记录
。
那InnoDB怎么区分 一条记录是普通的
用户记录
还是
目录项记录
呢？别忘了记录头信息里的
record_type
属性，它的各个取值代表的意思如下：
0：普通的用户记录
1：目录项记录
2：最小记录
3：最大记录
哈哈，原来这个值为1
的
record_type
是这个意思呀，我们把前边使用到的目录项放到数据页中的样子就是这样：
从图中可以看出来，我们新分配了一个编号为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条目录项记录（请注意是假设哦， 真实情况下可以存放好多条的），所以如果此时我们再向上图中插入一条主键值为320的用户记录的话，那就需要分配一个新的存储目录项记录的页：
从图中可以看出，我们插入了一条主键值为320
的用户记录之后需要两个新的数据页：
- 为存储该用户记录而新生成了页31。
- 因为原先存储目录项记录的页30的容量已满（我们前边假设只能存储4条目录项记录），所以不得不需要一个新的页32来存放页31对应的目录项。
现在因为存储目录项记录
的页不止一个，所以如果我们想根据主键值查找一条用户记录大致需要
3
个步骤，以查找主键值为
20
的记录为例：
1. 确定目录项记录
页
我们现在的存储目录项记录的页有两个，即
页
30
和
页
32
，又因为
页
30
表示的目录项的主键值的范围是
[1, 320)
，
页
32
表示的目录项的主键值不小于
320
，所以主键值为
20
的
记录对应的目录项记录在
页
30
中。
2. 通过目录项记录
页确定用户记录真实所在的页。
在一个存储目录项记录的页中通过主键值定位一条目录项记录的方式说过了，不赘述了～
3. 在真实存储用户记录的页中定位到具体的记录。
在一个存储用户记录的页中通过主键值定位一条用户记录的方式已经说过200遍了，你再不会就到上一篇唠叨数据页结构的文章中多看几遍 ～
那么问题来了，在这个查询步骤的第1
步中我们需要定位存储
目录项记录
的页，但是这些页在存储空间中也可能不挨着
，
如果我们表中的数据非常多则会产生很多存储目录项记 录的页，那我们怎么根据主键值快速定位一个存储目录项记录的页呢？
其实也简单，
为这些存储目录项记录的页再生成一个更高级的目录，就像是一个多级目录一样，大目录里嵌 套小目录，小目录里才是实际的数据
，所以现在各个页的示意图就是这样子：
如图，我们生成了一个存储更高级目录项的页
33
，这个页中的两条记录分别代表
页
30
和
页
32
，如果用户记录的主键值在
[1, 320)
之间，则到
页
30
中查找更详细的
目录项记录，如果主键值不小于
320
的话，就到
页
32
中查找更详细的
目录项记录
。
于是，简化一下上图就是可以得到最终的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+树与上边介绍的聚簇索引有几处不同：
1.使用记录c2列的大小进行记录和页的排序，这包括三个方面的含义：
- 页内的记录是按照c2列的大小顺序排成一个单向链表。
- 各个存放用户记录的页也是根据页中记录的c2列大小顺序排成一个双向链表。
- 存放目录项记录的页分为不同的层次，在同一层次中的页也是根据页中目录项记录的c2列大小顺序排成一个双向链表。
2.B+树的叶子节点存储的并不是完整的用户记录，而只是c2列+主键这两个列的值。
3.目录项记录中不再是主键
+
页号
的搭配，而变成了
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
（也就是
主键
）两个列，所以
我们必须再根据主键值去聚簇索引中再查找一遍完整的用户记录
。
看到步骤4
的操作了么？我们根据这个以
c2
列大小排序的
B+
树只能确定我们要查找记录的主键值，所以
如果我们想根据c2列的值查找到完整的用户记录的话，仍然需要到聚簇索引中再查一遍，这个过程也被称为
回表
。也就是根据
c2
列的值查询一条完整的用户记录需要使用到
2
棵
B+
树！！！
为什么我们还需要一次回表操作呢？直接把完整的用户记录放到叶子节点不就好了么？
你说的对，但如果把完整的用户记录放到
叶子节点
是可以不用
回表，但是太占地方了呀～相当于
每建立一棵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+树索引（聚簇索引不是人为创建的，默认就有）的时候，都会为这个索引创建一个根节点页面。最开始表中没有数据的时候，每个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
中。
一个页面最少存储两条记录
我们前边说过一个B+
树只需要很少的层级就可以轻松存储数亿条记录，查询速度杠杠的！这是因为
B+树本质上就是一个大的多层级目录，每经过一个目录时都会过滤掉许多 无效的子目录，直到最后访问到存储真实数据的目录。
那如果一个大的目录中只存放一个子目录是个啥效果呢？
那就是目录层级非常非常非常多，而且最后的那个存放真实数据的目录中只能存放一条记录。费了半天劲只能存放一条真实的用户记录？逗我呢？所以
InnoDB的一个数据页至少可以存放两条记录，这也是我们之前唠叨记录行格式的时候 说过一个结论（我们当时依据这个结论推导了表中只有一个列时该列在不发生行溢出的情况下最多能存储多少字节，忘了的话回去看看吧）。
MyISAM中的索引方案简单介绍
我们知道
InnoDB
中
索引即数据，也就是聚簇索引的那棵
B+
树的叶子节点中已经把所有完整的用户记录都包含了
，而
MyISAM的索引方案虽然也使用树形结构，但是却将索引和数据分开存储：
- 将表中的记录按照记录的插入顺序单独存储在一个文件中，称之为数据文件。这个文件并不划分为若干个数据页，有多少记录就往这个文件中塞多少记录就成了。我们可以通过行号而快速访问到一条记录。MyISAM记录也需要记录头信息来存储一些额外数据，我们以上边唠叨过的index_demo表为例，看一下这个表中的记录使用MyISAM作为存储引擎在存储空间中的表示：
- 由于在插入数据的时候并没有刻意按照主键大小排序，所以我们并不能在这些数据上使用二分法进行查找。
- 使用MyISAM存储引擎的表会把索引信息另外存储到一个称为索引文件的另一个文件中。MyISAM会单独为表的主键创建一个索引，只不过在索引的叶子节点中存储的不是完整的用户记录，而是主键值 + 行号的组合。也就是先通过索引找到对应的行号，再通过行号去找对应的记录！这一点和InnoDB是完全不相同的，在InnoDB存储引擎中，我们只需要根据主键值对聚簇索引进行一次查找就能找到对应的记录，而在MyISAM中却需要进行一次回表操作，意味着MyISAM中建立的索引相当于全部都是二级索引！
- 如果有需要的话，我们也可以对其它的列分别建立索引或者建立联合索引，原理和InnoDB中的索引差不多，不过在叶子节点处存储的是相应的列 + 行号。这些索引也全部都是二级索引。
小贴士： MyISAM的行格式有定长记录格式（Static）、变长记录格式（Dynamic）、压缩记录格式（Compressed）。上边用到的index_demo表采用定长记录格式，也就是一条记录占用存储空间的大小是固定的，这样就可以轻松算出某条记录在数据文件中的地址偏移量。但是变长记录格式就不行了，MyISAM会直接在索引叶子节点处存储该条记录在数据文件中的地址偏移量。通过这个可以看出，MyISAM的回表操作是十分快速的，因为是拿着地址偏移量直接到文件中取数据的，反观InnoDB是通过获取主键之后再去聚簇索引里边儿找记录，虽然说也不慢，但还是比不上直接用地址去访问。 此处我们只是非常简要的介绍了一下MyISAM的索引，
具体细节全拿出来又可以写一篇文章了。这里只是希望大家理解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;总结反思时刻
一，作者讲了什么？
- 本文主要讲InnoDB的的索引的设计思想，如何从一个普通的查找一步步优化到最终的B+树这种索引方式，即InnoDB的索引为什么要用B+树这种索引结构，而不是要用B树、红黑树等等？读这篇文章时要始终带着该问题去学习。
- MYISAM的索引方式
- MYSQL的索引基本语法
二，作者是怎么把这事给讲明白的？
先讲普通的的查找方式，然后从一个普通的查找一步步优化到最终的B+树这种索引方式，由浅入深，层层优化，要细细品味其中的优化思想。
三，为了讲明白，作者讲了哪些要点，有哪些亮点？
- 本文的图很清晰，一图胜千言，把握住其中的索引记录结构。
四，对作者所讲，我有哪些发散性思考？
- 本文主要讲为什么，怎么做下片文章再讲。
五，将来在哪些场景，我能够使用到它？
参考资料：
- 《MySQL 是怎样运行的：从根儿上理解 MySQL - 快捷方式》——_快速查询的秘籍 —— B+ 树索引