索引
索引是在存储引擎中实现的，因此每种存储引擎的索引不一定完全相同，并且每种存储引擎不一定支持所有索引类型。同时，存储引擎可以定义每个表的 最大索引数和 最大索引长度。所有存储引擎支持每个表至少16个索引，总索引长度至少为256字节。有些存储引擎支持更多的索引数和更大的索引长度。
存储引擎：InnoDB，MySQL5.5以后默认使用。
InnoDB中索引的数据结构为B+树。
B+树
注：
这部分不明白，可以参看《数据结构与算法》。
其实完全没必要，从头看，可能需要花费10几天时间，但是大学其实是必修的，这门课。
实际上，《数据结构与算法》关于多叉树，可能就概念性的提及。基本上就到平衡二叉树，这个代码已经相对比较复杂，让实现一个B+树，这个难度还是很高的。
最后，如果不心虚，只要在MySQL中的课程中，了解索引和B+树即可。
需求：快速修改和查找元素。
- 数组(排序后)：快速查找，增删繁琐，而且内存空间连续
- 链表：查找不易，增删简单，而且内存空间不要求连续
- 树是综合数组和链表的优缺点，是平衡之道。
树->二叉树->二叉排序树->平衡二叉树
->多叉树-----------> B树 ->B+树
树的推演：
二叉树：简单明了，就像二进制一样
二叉排序树：排序与查找，极端情况成为单链表
平衡二叉树：平衡左右子树的高度，使得树的高度最小，同时符合排序树的要求。
从二叉树到多叉树，再到B树
B树和B+树的区别是：B+树只有叶子节点是纪录，非叶子节点是目录
InnoDB中的索引方案
数据页大小：16kb，与操作系统(硬件)相关
数据页包括：目录页和纪录页
页内有页目录，所以在页面内可以通过二分法实现快速定位。
相比与内存中的排序比较查找，磁盘I/O所耗费的时间，不是一个数量级的。
树的每一层都是一次磁盘I/O，所以需要尽量减少树的高度，但是这个I/O还和数据页有关。
所以一个节点的大小就是一个数据页，一次磁盘I/O加载。
真实环境中一个页存放的记录数量是非常大的，假设所有存放用户记录的叶子节点代表的数据页可以存放 100条用户记录，所有存放目录项记录的内节点代表的数据页可以存放1000条目录项记录 。
B+树一般不会超过4层：
- 如果B+树只有1层，也就是只有1个用于存放用户记录的节点，最多能存放 100 条记录。
- 如果B+树有2层，最多能存放 1000×100=10,0000 条记录(10万)。
- 如果B+树有3层，最多能存放 1000×1000×100=1,0000,0000 条记录(1亿)。
- 如果B+树有4层，最多能存放 1000×1000×1000×100=1000,0000,0000 条记录(1000亿)。
常见索引概念
索引按照物理实现方式，索引可以分为 2 种：聚簇（聚集）和非聚簇（非聚集）索引。
聚簇索引
聚簇索引并不是一种单独的索引类型，而是一种数据存储方式（所有的用户记录都存储在了叶子结点），也就是所谓的 索引即数据，数据即索引。
所有完整的用户记录都存放在这个聚簇索引的叶子节点处。这种聚簇索引并不需要我们在MySQL语句中显式的使用INDEX 语句去创建， InnDB 存储引擎会 自动 的为我们创建聚簇索引。
优点：
数据访问更快，因为聚簇索引将索引和数据保存在同一个B+树中，因此从聚簇索引中获取数据比非聚簇索引更快- 聚簇索引对于主键的
排序查找和范围查找速度非常快 - 按照聚簇索引排列顺序，查询显示一定范围数据的时候，由于数据都是紧密相连，数据库不用从多 个数据块中提取数据，所以
节省了大量的io操作。
缺点：
插入速度严重依赖于插入顺序，按照主键的顺序插入是最快的方式，否则将会出现页分裂，严重影响性能。因此，对于InnoDB表，我们一般都会定义一个自增的ID列为主键更新主键的代价很高，因为将会导致被更新的行移动。因此，对于InnoDB表，我们一般定义主键为不可更新二级索引访问需要两次索引查找，第一次找到主键值，第二次根据主键值找到行数据
非聚簇索引
使用非主键列，构建索引，叶子节点的内容为构建的非主键列和主键列。
概念：回表
我们根据这个以c2列大小排序的B+树只能确定我们要查找记录的主键值，所以如果我们想根 据c2列的值查找到完整的用户记录的话，仍然需要到 聚簇索引 中再查一遍，这个过程称为 回表 。也就 是根据c2列的值查询一条完整的用户记录需要使用到 2 棵B+树！
小结：聚簇索引与非聚簇索引的原理不同，在使用上也有一些区别：
- 聚簇索引的
叶子节点存储的就是我们的数据记录, 非聚簇索引的叶子节点存储的是数据位置。非聚簇索引不会影响数据表的物理存储顺序。 - 一个表
只能有一个聚簇索引，因为只能有一种排序存储的方式，但可以有多个非聚簇索引，也就是多个索引目录提供数据检索。 - 使用聚簇索引的时候，数据的
查询效率高，但如果对数据进行插入，删除，更新等操作，效率会比非聚簇索引低。
联合索引
同时以多个列的大小作为排序规则，也就是同时为多个列建立索引，比方说我们想让B+树按 照 c2和c3列 的大小进行排序，这个包含两层含义：
- 先把各个记录和页按照c2列进行排序。
- 在记录的c2列相同的情况下，采用c3列进行排序
如图所示，我们需要注意以下几点：
- 每条目录项都有c2、c3、页号这三个部分组成，各条记录先按照c2列的值进行排序，如果记录的c2列相同，则按照c3列的值进行排序
- B+树叶子节点处的用户记录由c2、c3和主键c1列组成
注意一点，以c2和c3列的大小为排序规则建立的B+树称为 联合索引 ，本质上也是一个二级索引。它的意 思与分别为c2和c3列分别建立索引的表述是不同的，不同点如下：
- 建立 联合索引 只会建立如上图一样的1棵B+树。
- 为c2和c3列分别建立索引会分别以c2和c3列的大小为排序规则建立2棵B+树。
索引的代价
索引是个好东西，可不能乱建，它在空间和时间上都会有消耗：
- 空间上的代价
每建立一个索引都要为它建立一棵B+树，每一棵B+树的每一个节点都是一个数据页，一个页默认会 占用 16KB 的存储空间，一棵很大的B+树由许多数据页组成，那就是很大的一片存储空间。
- 时间上的代价
每次对表中的数据进行 增、删、改 操作时，都需要去修改各个B+树索引。而且我们讲过，B+树每 层节点都是按照索引列的值 从小到大的顺序排序 而组成了 双向链表 。不论是叶子节点中的记录，还 是内节点中的记录（也就是不论是用户记录还是目录项记录）都是按照索引列的值从小到大的顺序 而形成了一个单向链表。而增、删、改操作可能会对节点和记录的排序造成破坏，所以存储引擎需 要额外的时间进行一些 记录移位 ， 页面分裂 、 页面回收 等操作来维护好节点和记录的排序。如果 我们建了许多索引，每个索引对应的B+树都要进行相关的维护操作，会给性能拖后腿。
索引的创建与删除
创建表的时候创建索引
基本语法格式如下：
CREATE TABLE table_name [col_name data_type]
[UNIQUE | FULLTEXT | SPATIAL] [INDEX | KEY] [index_name] (col_name [length]) [ASC | DESC]
在book表中的year_publication字段上建立普通索引，SQL语句如下：
CREATE TABLE book(
book_id INT ,
book_name VARCHAR(100),
authors VARCHAR(100),
info VARCHAR(100) ,
comment VARCHAR(100),
year_publication YEAR,
INDEX(year_publication)
);
在已经存在的表上创建索引
ALTER TABLE
ALTER TABLE语句创建索引的基本语法如下：
ALTER TABLE table_name ADD [UNIQUE | FULLTEXT | SPATIAL] [INDEX | KEY]
[index_name] (col_name[length],...) [ASC | DESC]
CREATE INDEX
CREATE INDEX语句可以在已经存在的表上添加索引，在MySQL中， CREATE INDEX被映射到一个ALTER TABLE语句上，基本语法结构为：
CREATE [UNIQUE | FULLTEXT | SPATIAL] INDEX index_name
ON table_name (col_name[length],...) [ASC | DESC]
删除索引
ALTER TABLE删除索引的基本语法格式如下：
ALTER TABLE table_name DROP INDEX index_name;
DROP INDEX删除索引的基本语法格式如下：
DROP INDEX index_name ON table_name;
最后总结
理论很高深，实操一句话。
适用于许多工程技术。毕竟工程技术就是要简化操作。能简应简，约定优于配置。
最后，没事别创建索引，除非真的有特别需要，而且最好是数据库管理者进行创建和优化。
