基于mysql的数据库索引使用背后的原理
1：什么是索引
MySQL官方对索引的定义为：索引（Index）是帮助MySQL高效获取数据的数据结构。
简单来说：索引是一种数据结构
复杂来说：数据库在肩负着存储数据之外，还要查询数据，那么如何查询数据呢？最基本的，顺序查找，但是数据量较大时耗时（O（n）），
优化查询方式，比如二分查找，需要特定的数据结构支持，所以需要一种数据结构支持高级的搜索算法，这个数据结构就是索引。
2：索引用的什么数据结构？为什么用这种数据结构？
索引的数据结构：b+树，
原因：数据库读取数据涉及到磁盘io,可以从这个角度对比二叉树/b+;b-/b+;
交代一下背景：机械硬盘时代，索引数据较多；
二叉树/b+对比：
1：二叉树：由于索引数据较多，占用空间较大，无法一次加载到内存中，由图2-1-1至2-2-5所示，树的高度是4，查询的值的节点也在第四层，即最坏情况磁盘io次数等于树的高度。那么如果和优化呢？将瘦高的二叉树变成矮胖的树，这样就可以减少树的高度，减少io次数，所以出现了b-tree
b-tree/b+对比：
2-1-1
2-1-2
2-1-3
2-1-4
2-1-5
2：b树
什么是b-tree呢？满足一下条件：针对m阶b-tree,如图2-2-1，
1:根节点至少有个俩棵子树，
2：每个分结点至少有个m/2棵子树，至多有m棵子树
3：每个叶子节点都在同一层
4：每个分节点最多有个m-1个键，m个指针，并且按键值升序排列
b-tree的优点：越靠近根节点搜索越快，因为key直接对应data
但是有一个缺点：内存中一页为16k,b-tree的节点是携带data,极端情况下，若数据过多则会导致查询多次翻页，多次磁盘io影响性能，此时b+tree应运而生。
2-2-1
3:b+树，如图2-3-1
b+tree是对b-tree的优化，通过图2-2-1 和 2-3-1 的对比可以发现
1：b+tree除了叶子节点外没有携带数据,所以一页内存可以装在更多的信息
2：叶子节点以一根指针相连
3：数据都存储在叶子节点
4：b-/b+对比
最重要的就是磁盘io的次数对比，在这里引用一个理论上的计算:{
InnoDB存储引擎中页的大小为16KB，一般表的主键类型为INT（占用4个字节）或BIGINT（占用8个字节），指针类型也一般为4或8个字节，也就是说一个页（B+Tree中的一个节点）中大概存储16KB/(8B+8B)=1K个键值（因为是估值，为方便计算，这里的K取值为〖10〗^3）。也就是说一个深度为3的B+Tree索引可以维护10^3 * 10^3 * 10^3 = 10亿 条记录。
}
实际上每一个节点基本不可能填满，一般一颗b+tree为2-4层，1-3次检索。
2-3-1
索引都包含哪些
为什么用索引快,以及可能遇到的问题
1：举个简单的例子：有俩百万的数据，找到最后一条数据id=2000000（俩百万），是顺序查找快还是利用索引直接定位快，显然索引快，这就是为什么用索引。
2：上面都在说使用索引的好处，但过多的使用索引将会造成滥用。因此索引也会有它的缺点：虽然索引大大提高了查询速度，同时却会降低更新表的速度，如对表进行INSERT、UPDATE和DELETE。因为更新表时，MySQL不仅要保存数据，还要保存一下索引文件。建立索引会占用磁盘空间的索引文件。一般情况这个问题不太严重，但如果你在一个大表上创建了多种组合索引，索引文件的会膨胀很快。索引只是提高效率的一个因素，如果你的MySQL有大数据量的表，就需要花时间研究建立最优秀的索引，或优化查询语句。下面是一些总结以及收藏的MySQL索引的注意事项和优化方法。
单独说一下 聚集索引和非聚集索引
聚集索引：
是按照数据存放的物理位置为顺序
非聚集索引：
是按照数据存放的逻辑顺序为顺序,
其他的索引，比如唯一索引可能是聚集索引，都是属于聚集索引或者非聚集索引
普通索引
在某一类上创建索引；
–直接创建索引
CREATE INDEX index_name ON table(column(length))
–修改表结构的方式添加索引
ALTER TABLE table_name ADD INDEX index_name ON (column(length))
–删除索引
DROP INDEX index_name ON table
唯一索引
索引列必须唯一，可以为空
创建唯一索引
CREATE UNIQUE INDEX indexName ON table(column(length))
–修改表结构
ALTER TABLE table_name ADD UNIQUE indexName ON (column(length))
全文索引
MySQL从3.23.23版开始支持全文索引和全文检索，FULLTEXT索引仅可用于 MyISAM 表；他们可以从CHAR、VARCHAR或TEXT列中作为CREATE TABLE语句的一部分被创建，或是随后使用ALTER TABLE 或CREATE INDEX被添加。////对于较大的数据集，将你的资料输入一个没有FULLTEXT索引的表中，然后创建索引，其速度比把资料输入现有FULLTEXT索引的速度更为快。不过切记对于大容量的数据表，生成全文索引是一个非常消耗时间非常消耗硬盘空间的做法。
–修改表结构添加全文索引
ALTER TABLE article ADD FULLTEXT index_content(content)
–直接创建索引
CREATE FULLTEXT INDEX index_content ON article(content)
单列索引，多列索引
多个单列索引与单个多列索引的查询效果不同，因为执行查询时，MySQL只能使用一个索引，会从多个索引中选择一个限制最为严格的索引
组合索引（最左索引）,这个索引很有意思
平时用的SQL查询语句一般都有比较多的限制条件，所以为了进一步榨取MySQL的效率，就要考虑建立组合索引。例如上表中针对title和time建立一个组合索引：ALTER TABLE article ADD INDEX index_titme_time (title(50),time(10))。建立这样的组合索引，其实是相当于分别建立了下面两组组合索引：
–title,time
–title
为什么没有time这样的组合索引呢？这是因为MySQL组合索引“最左前缀”的结果。简单的理解就是只从最左面的开始组合。并不是只要包含这两列的查询都会用到该组合索引，如下面的几个SQL所示：
–使用到上面的索引
SELECT * FROM article WHREE title='测试' AND time=1234567890;
SELECT * FROM article WHREE utitle='测试';
–不使用上面的索引
SELECT * FROM article WHREE time=1234567890;
索引怎么使用
1. 何时使用聚集索引或非聚集索引？
动作描述 使用聚集索引 使用非聚集索引
列经常被分组排序 使用 使用
返回某范围内的数据 使用 不使用
一个或极少不同值 不使用 不使用
小数目的不同值 使用 不使用
大数目的不同值 不使用 使用
频繁更新的列 不使用 使用
外键列 使用 使用
主键列 使用 使用
频繁修改索引列 不使用 使用
事实上，我们可以通过前面聚集索引和非聚集索引的定义的例子来理解上表。如：返回某范围内的数据一项。比如您的某个表有一个时间列，恰好您把聚合索引建立在了该列，这时您查询2004年1月1日至2004年10月1日之间的全部数据时，这个速度就将是很快的，因为您的这本字典正文是按日期进行排序的，聚类索引只需要找到要检索的所有数据中的开头和结尾数据即可；而不像非聚集索引，必须先查到目录中查到每一项数据对应的页码，然后再根据页码查到具体内容。其实这个具体用法我还不是很理解，只能等待后期的项目开发中慢慢学学了。
2. 索引不会包含有NULL值的列
只要列中包含有NULL值都将不会被包含在索引中，复合索引中只要有一列含有NULL值，那么这一列对于此复合索引就是无效的。所以我们在数据库设计时不要让字段的默认值为NULL。
3. 使用短索引
对串列进行索引，如果可能应该指定一个前缀长度。例如，如果有一个CHAR(255)的列，如果在前10个或20个字符内，多数值是惟一的，那么就不要对整个列进行索引。短索引不仅可以提高查询速度而且可以节省磁盘空间和I/O操作。
4. 索引列排序
MySQL查询只使用一个索引，因此如果where子句中已经使用了索引的话，那么order by中的列是不会使用索引的。因此数据库默认排序可以符合要求的情况下不要使用排序操作；尽量不要包含多个列的排序，如果需要最好给这些列创建复合索引。
5. like语句操作
一般情况下不鼓励使用like操作，如果非使用不可，如何使用也是一个问题。like “%aaa%” 不会使用索引而like “aaa%”可以使用索引。
6. 不要在列上进行运算
例如：select * from users where YEAR(adddate)<2007，将在每个行上进行运算，这将导致索引失效而进行全表扫描，因此我们可以改成：select * from users where adddate<’2007-01-01′。关于这一点可以围观：一个单引号引发的MYSQL性能损失。
小结
最后总结一下，MySQL只对一下操作符才使用索引：<,<=,=,>,>=,between,in,以及某些时候的like(不以通配符%或_开头的情形)。而理论上每张表里面最多可创建16个索引，不过除非是数据量真的很多，否则过多的使用索引也不是那么好玩的，比如我刚才针对text类型的字段创建索引的时候，系统差点就卡死了。
索引的优缺点
为什么要创建索引呢？
这是因为，创建索引可以大大提高系统的性能。
第一、通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性。
第二、可以大大加快 数据的检索速度，这也是创建索引的最主要的原因。
第三、可以加速表和表之间的连接，特别是在实现数据的参考完整性方面特别有意义。
第四、在使用分组和排序子句进行数据检索时，同样可以显著减少查询中分组和排序的时间。
第五、通过使用索引，可以在查询的过程中，使用优化隐藏器，提高系统的性能。
也许会有人要问：增加索引有如此多的优点，为什么不对表中的每一个列创建一个索引呢？这种想法固然有其合理性，然而也有其片面性。虽然，索引有许多优点， 但是，为表中的每一个列都增加索引，是非常不明智的。
这是因为，增加索引也有许多不利的一个方面:
第一、创建索引和维护索引要耗费时间，这种时间随着数据量的增加而增加。
第二、索引需要占物理空间，除了数据表占数据空间之外，每一个索引还要占一定的物理空间。如果要建立聚簇索引，那么需要的空间就会更大。
第三、当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，这样就降低了数据的维护速度。
什么样的字段适合创建索引:
索引是建立在数据库表中的某些列的上面。因此，在创建索引的时候，应该仔细考虑在哪些列上可以创建索引，在哪些列上不能创建索引。
一般来说，应该在这些列上创建索引，例如：
第一、在经常需要搜索的列上，可以加快搜索的速度；
第二、在作为主键的列上，强制该列的唯一性和组织表中数据的排列结构；
第三、在经常用在连接的列上，这些列主要是一些外键，可以加快连接的速度；
第四、在经常需要根据范围进行搜索的列上创建索引，因为索引已经排序，其指定的范围是连续的；
第五、在经常需要排序的列上创建索引，因为索引已经排序，这样查询可以利用索引的排序，加快排序查询时间；
第六、在经常使用在WHERE子句中的列上面创建索引，加快条件的判断速度。
建立索引，一般按照select的where条件来建立，比如： select的条件是where f1 and f2，那么如果我们在字段f1或字段f2上简历索引是没有用的，只有在字段f1和f2上同时建立索引才有用等。
什么样的字段不适合创建索引:
同样，对于有些列不应该创建索引。一般来说，不应该创建索引的的这些列具有下列特点：
第一，对于那些在查询中很少使用或者参考的列不应该创建索引。这是因为，既然这些列很少使用到，因此有索引或者无索引，
并不能提高查询速度。相反，由于增加了索引，反而降低了系统的维护速度和增大了空间需求。
第二，对于那些只有很少数据值的列也不应该增加索引。这是因为，由于这些列的取值很少，例如人事表的性别列，
在查询的结果中，结果集的数据行占了表中数据行的很大比 例，即需要在表中搜索的数据行的比例很大。
增加索引，并不能明显加快检索速度。
第三，对于那些定义为text, image和bit数据类型的列不应该增加索引。这是因为，这些列的数据量要么相当大，要么取值很少。
第四，当修改性能远远大于检索性能时，不应该创建索 引。这是因为，修改性能和检索性能是互相矛盾的。
当增加索引时，会提高检索性能，但是会降低修改性能。当减少索引时，会提高修改性能，降低检索性能。
因此，当修改性能远远大于检索性能时，不应该创建索引。
创建索引的方法::
1、创建索引，例如 create index <索引的名字> on table_name (列的列表);
2、修改表，例如 alter table table_name add index[索引的名字] (列的列表);
3、创建表的时候指定索引，例如create table table_name ( [...], INDEX [索引的名字] (列的列表) );
查看表中索引的方法:
show index from table_name; 查看索引
索引的类型及创建例子::
1.PRIMARY KEY （主键索引）
MySQL> alter table table_name add primary key ( `column` )
2.UNIQUE 或 UNIQUE KEY (唯一索引)
mysql> alter table table_name add unique (`column`)
3.FULLTEXT (全文索引)
mysql> alter table table_name add fulltext (`column` )
4.INDEX (普通索引)
mysql> alter table table_name add index index_name ( `column` )
5.多列索引 (聚簇索引)
mysql> alter table `table_name` add index index_name ( `column1`, `column2`, `column3` )