Today, let's talk about clustered and non-clustered indexes;
When I first started to learn database SQL, I knew that there were primary keys, foreign keys, etc. Even a table query was not clear about which fields to be on. If it is not too big, the index will not be considered at all. Then, with the advent of the era of big data, the amount of data is huge, and it is not necessary to have no index. Customers complain again, do you know, you Do you know, I wait until the flowers are all thanks to the birds. . . . . There is no index, and it is completely dependent on the blunt where condition. After reaching millions of data records, if there is no primary key, the page loading is slower than that, and the query page may be directly closed by the user in minutes, and the rest you wait for the product manager. Let's rant again. . . . .
OK, no more gossip, let's get down to business, then let's find out:
(The following is only for newcomers to learn and exchange and personal experience. The database god can directly ignore it. If there is anything inappropriate, welcome the god Yazheng.)
- what is an index;
- What are clustered and non-clustered indexes;
- Why build an index;
- Try it out and see how the code works;
- Performance comparison and analysis;
What is an index.
Let's take a look at the more popular definition, OK, then go directly to Baidu Encyclopedia: "An index is a structure that sorts the values of one or more columns in a database table, and an index can be used to quickly access specific information in a database table. "Look at the central language-keyword [a structure], in the final analysis, the index is a thing that sorts the values of the data column in a structured way.
Let’s talk about it in layman’s terms. Do you still remember the military training in the university, when everyone put on camouflage uniforms on the first day and went to the sports field or field military training ground for military training, they usually got together in a mess, and the military training instructor came. , The instructor looked at everyone, there were males and females, tall and short, and within a few minutes, they quickly arranged the group into m rows and n columns. Name everyone, 'X row and y column (or student number xx), Wang Dachui, get out of the queue!' With an order, Wang Dachui came out of the queue,...
In this scene, the instructor is the best [index] on the military training ground;
What are clustered and non-clustered indexes
With the concept of index recognition, clustered index and non-clustered index are easy to understand. Let's talk about the simplest example;
【Clustered Index】
平时习惯逛图书馆的童鞋可能比较清楚，如果你要去图书馆借一本书，最开始是去电脑里面查书名然后根据书名来定位藏书在那个区，哪个书柜，哪一行，第多少本。。。清晰明确，一目了然，因为藏书的结构与图书室的位置，书架的顺序，书本的摆放顺序与书籍的编号都是从大到小一致的顺序摆放的，所以很容易找到。比如，你的目标藏书在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/)]曾经总结过的几句话来描述一下索引的使用原则：
总结索引使用原则：
不要索引数据量不大的表，对于小表来讲，表扫描的成本并不高。
不要设置过多的索引，在没有聚集索引的表中，最大可以设置249个非聚集索引，过多的索引首先会带来更大的磁盘空间，而且在数据发生修改时，对索引的维护是特别消耗性能的。
合理应用复合索引，有某些情况下可以考虑创建包含所有输出列的覆盖索引。
对经常使用范围查询的字段，可能考虑聚集索引。
避免对不常用的列，逻辑性列，大字段列创建索引。