本文默认针对的MySQL引擎为InnoDB。
索引的分类
其实InnoDB引擎支持3种常见的索引：B+树索引、全文索引、哈希索引。
- B+树索引是传统意义上的索引，这是目前关系型数据库系统中查找最为常用和最为有效的索引，常说的普通索引、唯一索引、主键索引、联合索引、覆盖索引（从辅助索引中就可以得到查询的记录而不需要查询聚集索引，它不需要手动创建，是优化器自动选择的结果）、前缀索引（无法使用前缀索引做 ORDER BY 和 GROUP BY，也无法使用前缀索引做覆盖扫描）等都是B+树索引的类型；
- 全文索引是将存储于数据库中的整本书或整篇文章中的任意内容信息查找出来的技术，它可以根据需要获得全文中匹配的信息，用于支持select * from blog where content like ‘%xxx%’的形式（前缀的形式‘xxx%’在B+树索引中是支持的）；
- 哈希索引在InnoDB引擎中是自适应的，不能通过人为干预是否在一张表中生成哈希索引，哈希索引只能用来搜索等值的查询如“select * from table where c1=’niu’”，其他的查找类型是不能使用哈希索引的。
B+树索引进行介绍：
聚簇索引
聚簇索引就是按照每张表的主键构造一棵B+树，同时叶子节点中存放的即为整张表的行记录数据，也将聚集索引的叶子节点称为数据页。值得注意的是，如果一个表没有指定主键，那么MySQL服务器会自动为我们添加一个row_id作为主键，这部分内容需要参考InnoDB行记录格式部分的内容。
辅助索引
非聚簇索引在其他文章中又称为：二级索引、非聚簇索引。它的设计目的是为了加快不使用主键进行查询的情景，它的叶子节点中并不包含行记录的全部数据，除了包含指定的键值（这里的键值可以是普通索引、唯一索引、联合索引），还包含主键。例如以c1列的大小进行记录和页的排序，由此建立的B+树的叶子节点存储的不是完成的用户记录，而只是c1和主键这两个列的值，我们根据这个以c1列大小排序的B+树只能确定我们要查找记录的主键值，所以如果我们想根据c1列的值查找到完整的用户记录的话，仍然需要到聚簇索引中再查一遍，这个过程也被称为回表。也就是根据c1列的值查询一条完整的用户记录需要使用到2棵B+树！！！
为什么我们还需要一次回表操作呢？直接把完整的用户记录放到叶子节点不就好了么？如果把完整的用户记录放到叶子节点是可以不用回表，但是太占地方了呀～相当于每建立一棵B+树都需要把所有的用户记录再都拷贝一遍，这就有点太浪费存储空间了。因为这种按照非主键列建立的B+树需要一次回表操作才可以定位到完整的用户记录，所以这种B+树也被称为二级索引（英文名secondary index），或者辅助索引。由于我们使用的是c1列的大小作为B+树的排序规则，所以我们也称这个B+树为为c1列建立的索引。（MySQL的索引）
索引的使用
一般来说，索引的建立遵循一下几个原则：
- 为经常需要ORDER BY、GROUP BY、ON、DISTINCT和UNION等操作的字段进行索引
- 为经常作为查询条件的字段建立索引
- 尽量使用数据量少的索引（TEXT/BOLB等不适合建立索引）
- 使用索引应当尽量避免 “OR” 、“否定查询” 、“模糊查询”、“NOT IN”、“<>” 等操作
- 索引不会包含有NULL值的列
- 不要滥用索引，虽然索引可以提高查询效率，但是要控制建立的索引数量，因为每添加一个索引，就会建立一个B+树，每插入一条记录都要维护这些树，这么做很浪费性能和存储空间
- 如果索引字段值很长，使用前缀索引
参考链接：