MySQL索引
MySQL索引的建立对于MySQL的高效运行是很重要的，索引可以大大提高MySQL的检索速度。
可以类比字典，如果要查“mysql”这个单词，我们肯定需要定位到m字母，然后从下往下找到y字母，再找到剩下的sql。如果没有索引，那么你可能需要把所有单词看一遍才能找到你想要的，如果我想找到m开头的单词呢？或者ze开头的单词呢？是不是觉得如果没有索引，这个事情根本无法完成？
索引类型
MySQL目前主要有以下几种索引类型：
1.普通索引
2.唯一索引
3.主键索引
4.组合索引
5.全文索引
索引创建
普通索引
这是最基本的索引，它没有任何限制。创建方式：
CREATE INDEX indexName ON table_name (column_name)
唯一索引
它与前面的普通索引类似，不同的就是：索引列的值必须唯一，但允许有空值。如果是组合索引，则列值的组合必须唯一。创建方式：
CREATE UNIQUE INDEX indexName ON table_name (username(length))
主键索引
是一种特殊的唯一索引，一个表只能有一个主键，不允许有空值。一般是在建表的时候同时创建主键索引：
CREATE TABLE `table_name` (`id` int(11) NOT NULL AUTO_INCREMENT ,`title` char(255) NOT NULL ,PRIMARY KEY (`id`));
组合索引
指多个字段上创建的索引，只有在查询条件中使用了创建索引时的第一个字段，索引才会被使用。使用组合索引时遵循最左前缀集合：
ALTER TABLE `table_name` ADD INDEX name_city_age (name,city,age);
全文索引
全文索引（也称全文检索）是目前搜索引擎使用的一种关键技术。它能够利用【分词技术】等多种算法智能分析出文本文字中关键词的频率和重要性，然后按照一定的算法规则智能地筛选出我们想要的搜索结果。
创建方式：
CREATE FULLTEXT INDEX index_content ON table_name(content)
索引的数据结构
首先，数据库索引使用树来存储，因为树的查询效率高，而且二叉查找树还可以保持数据的有序。
那么索引为什么没有使用二叉树来实现呢？
其实从算法逻辑上讲，二叉查找树的查找速度和比较次数都是最小的，但是从Mysql的角度讲，我们不得不考虑一个现实问题：磁盘IO。
当我们利用索引查询的时候，不可能把整个索引全部加载到内存，只能逐一加载每个磁盘页，磁盘页对应索引树的节点。
那么Mysql衡量查询效率的标准就是磁盘IO次数。
如果我们利用二叉树作为索引结构，那么磁盘的IO次数和索引树的高度是相关的。
那么为了提高查询效率，就需要减少磁盘IO数。为了减少磁盘IO的次数，就需要尽量降低树的高度，需要把原来“瘦高”的树结构变的“矮胖”，树的每层的分叉越多越好，因此b+树正好符合我们的要求。
b+树
b+ 树的特点是能够保持数据稳定有序，其插入与修改拥有较稳定的对数时间复杂度。
我们先来看看b+树存储结构，比如有一张用户表（user），数据如下：
id |
其他字段 |
3 |
|
5 |
|
9 |
|
10 |
|
13 |
|
15 |
|
28 |
|
29 |
|
36 |
|
60 |
|
75 |
|
79 |
|
91 |
|
95 |
相应b+树，如下图：
编辑
如上图，这就是一个b+树。其中浅蓝色的块我们称之为一个磁盘块，可以看到每个磁盘块包含几个数据项（深蓝色所示）和指针（黄色所示），如磁盘块1包含数据项17和35，包含指针P1、P2、P3，P1表示小于17的磁盘块，P2表示在17和35之间的磁盘块，P3表示大于35的磁盘块。真实的数据存在于叶子节点即3、5、9、10、13、15、28、29、36、60、75、79、91、95。非叶子节点只不存储真实的数据，只存储指引搜索方向的数据项，如17、35并不真实存在于数据表中。
b+树的查找过程
比如，查询id为29的记录：
select * from where id=29
如上图所示，如果要查找数据项29，那么首先会把磁盘块1由磁盘加载到内存，此时发生一次IO，在内存中用二分查找确定29在17和35之间，锁定磁盘块1的P2指针，内存时间因为非常短（相比磁盘的IO）可以忽略不计，通过磁盘块1的P2指针的磁盘地址把磁盘块3由磁盘加载到内存，发生第二次IO，29在26和30之间，锁定磁盘块3的P2指针，通过指针加载磁盘块8到内存，发生第三次IO，同时内存中做二分查找找到29，结束查询，总计三次IO。
真实的情况是，3层的b+树可以表示上百万的数据，如果上百万的数据查找只需要三次IO，性能提高将是巨大的，如果没有索引，每个数据项都要发生一次IO，那么总共需要百万次的IO，显然成本非常非常高。
缺点
上面说明都是索引的优点，索引同样的也存在缺点：
1.虽然索引大大提高了查询速度，同时却会降低更新表的速度，如对表进行insert、update和delete。因为更新表时，不仅要保存数据，还要保存一下索引文件。
2.建立索引会占用磁盘空间的索引文件。一般情况这个问题不太严重，但如果你在一个大表上创建了多种组合索引，索引文件的会增长很快。
3.索引只是提高效率的一个因素，如果有大数据量的表，就需要花时间研究建立最优秀的索引，或优化查询语句。
最后
MySQL改善查询性能改善的最好方式，只有我们明白索引的原理，才能更合理地使用索引！
