简析数据库索引

　　刚开始学数据库SQL的时候，就知道有主键啊(Primary-key)，外键啊(Foreign-key)啥的，连个表查询就已经不清楚是要on 那几个字段了，在数据量不太大的情况下，根本不会考虑索引的问题了，然后，随着大数据时代的到来，数据量大了，没有索引那是要不得的啊，客户又吐槽了，你知不知道，你知不知道，我等到花儿都谢鸟。。。。。没有索引，完全依赖生硬的where条件，达到百万级数据记录之后，如果没有主键，页面加载慢的一比，查询页面分分钟可能被用户直接关闭，剩下的你就等着 产品经理的一顿又一顿吐槽了吧。。。。。

OK，闲话不多扯了，言归正传，那我们来了解一下：

(一下仅供新人学习交流与个人体会，数据库大神可直接无视，若有不当之处，欢迎大神雅正.)

• 什么是索引；
• 什么是聚簇索引和非聚簇索引;
• 为什么要建索引;
• 动手试试，看看代码怎么敲的；
• 性能比较与分析；

什么是索引.

我们来看看比较大众的定义,OK,那就直接百度百科吧:"索引是对数据库表中一列或多列的值进行排序的一种结构，使用索引可快速访问数据库表中的特定信息。" 看中心语-关键词[一种结构],说到底索引就是对数据列的值进行结构化排序的一个东西.

通俗点讲吧. 还记得大学军训的时候吗,大伙第一天穿上迷彩服到运动场或者野外军训场地进行军训的时候,一般都是乱扎堆的吧,乱成一团,结果军训的教官来了,教官一看大伙,有男有女,有高有矮 几分钟很快就把大伙排成了m行n列的方针，尽然有序，高低有序；而且没多久教官还能很快滴说出大家的名字，‘x行y列（或者xx号学员），王大锤，出列!’ 一声令下，王大锤就从队列中走出来了，...

这段场景中，教官就是军训场地上最好的【索引】；

什么是聚簇索引和非聚簇索引

有了索引的概念认知，聚簇索引和非聚簇索引就好理解了,说一个最简单的例子吧；

【聚簇索引】

平时习惯逛图书馆的童鞋可能比较清楚，如果你要去图书馆借一本书，最开始是去电脑里面查书名然后根据书名来定位藏书在那个区，哪个书柜，哪一行，第多少本。。。清晰明确，一目了然，因为藏书的结构与图书室的位置，书架的顺序，书本的摆放顺序与书籍的编号都是从大到小一致的顺序摆放的，所以很容易找到。比如，你的目标藏书在C区2柜3排5仓，那么你走到B区你就很快知道前面就快到了C区了，你直接奔着2柜区就能找到了。 这就是雷同于聚簇索引的功效了，聚簇索引，实际存储的循序结构与数据存储的物理机构是一致的，所以通常来说物理顺序结构只有一种，那么一个表的聚簇索引也只能有一个，通常默认都是主键，设置了主键，系统默认就为你加上了聚簇索引，当然有人说我不想拿主键作为聚簇索引，我需要用其他字段作为索引，当然这也是可以的，这就需要你在设置主键之前自己手动的先添加上唯一的聚簇索引，然后再设置主键，这样就木有问题啦。

总而言之，聚簇索引是顺序结构与数据存储物理结构一致的一种索引，并且一个表的聚簇索引只能有唯一的一条；

【非聚簇索引】

同样的，如果你去的不是图书馆，而是某城市的商业性质的图书城，那么你想找的书就摆放比较随意了，由于商业图书城空间比较紧正，藏书通常按照藏书上架的先后顺序来摆放的，所以如果查询到某书籍放在C区2柜3排5仓，但你可能要绕过F区，而不是A.B.C.D...连贯一致的，也可能同在C区的2柜，书柜上第一排是计算机类的书记，也可能最后一排就是医学类书籍；
那么对照着来看非聚簇索引的概念就比较好理解了，非聚簇索引记录的物理顺序与逻辑顺序没有必然的联系，与数据的存储物理结构没有关系；一个表对应的非聚簇索引可以有多条，根据不同列的约束可以建立不同要求的非聚簇索引；

为什么要建索引

这个问题肯定很简单啦，看了上面的描述就知道了，肯定是为了加快找到目标数据的速度，节约查找话费的时间啦，用数据库属于来描述就是 ：

建立索引的目的是加快对表中记录的查找或排序。
但是话又说回来了，有了索引是不是就以为的数据的查询快得不要不要的，。。。。
或者说，添加了索引之后，查询速度一定回避没有添加索引的情况下更快？ 我看未必哦。。。

我们还是先了解一下 建立索引需要付出的代价和带来的弊端：

一.增加了数据库的存储空间，

二.在插入和修改数据时要花费较多的时间(因为索引也要随之变动)；

我们假设在一张表中的一条记录在磁盘上占用1KB话，我们对其中10B的一个字段建立索引，那么该记录对应的索引块的大小只有10B，如果一张表的的数据量比较大，大约100,000条，那么用来存储索引耗费的空间就是100,000X10B=1000,000B=10000KB=1MB,换句话说，这张白表也因为这个索引的建立而多使用了大约1MB的存储空间，当然对与大批量数据来说，这么点空间是不足为道的。但事实是，索引确实耗费了更多空间；

关于第二条我就不用赘述了，这个文字描述已经说的很清楚；

还有就是，对某些场景下，数据量不是特别大的情况下，对于某些添加索引的行为，不但不能优化查询速度，反而会减慢查询速度，当然，如果索引的建立不恰当，所选择建立索引的字段不合适，也可能会削弱查询速度，当然在数据量不大的情况下，基于SQL服务器本身强大的处理能力，这种削弱表现是非常微弱的，但是一旦数据量大起来,原本可以不需要考虑索引就能很快查询出来数据的，结果因为添加了索引反而加重了查询数据的消耗，不恰当的索引方式造成的影响就会表现的很明显；

所以，索引不是万能的，某些情况下，添加索引可能比不添加索引更慢！

最后引用别人[姜敏(http://www.cnblogs.com/aspnet2008/)]曾经总结过的几句话来描述一下索引的使用原则：

总结索引使用原则：

1. 不要索引数据量不大的表，对于小表来讲，表扫描的成本并不高。

2. 不要设置过多的索引，在没有聚集索引的表中，最大可以设置249个非聚集索引，过多的索引首先会带来更大的磁盘空间，而且在数据发生修改时，对索引的维护是特别消耗性能的。

3. 合理应用复合索引，有某些情况下可以考虑创建包含所有输出列的覆盖索引。

4. 对经常使用范围查询的字段，可能考虑聚集索引。

5. 避免对不常用的列，逻辑性列，大字段列创建索引。