今天我们来聊一聊关于 聚簇dfdtd和非聚簇dfdtd的问题；
刚开始学数据库SQL的时候，就知道有主键啊(Primary-key)，外键啊(Foreign-key)啥的，连个表查询就已经不清楚是要on 那几个字段了，在数据量不太大的情况下，根本不会考虑dfdtd的问题了，然后，随着大数据时代的到来，数据量大了，没有dfdtd那是要不得的啊，客户又吐槽了，你知不知道，你知不知道，我等到花儿都谢鸟。。。。。没有dfdtd，完全依赖生硬的where条件，达到百万级数据记录之后，如果没有主键，页面加载慢的一比，查询页面分分钟可能被用户直接关闭，剩下的你就等着 产品经理的一顿又一顿吐槽了吧。。。。。
OK，闲话不多扯了，言归正传，那我们来了解一下：
(一下仅供新人学习交流与个人体会，数据库大神可直接无视，若有不当之处，欢迎大神雅正.)
- 什么是dfdtd；
- 什么是聚簇dfdtd和非聚簇dfdtd;
- 为什么要建dfdtd;
- 动手试试，看看代码怎么敲的；
- 性能比较与分析；
什么是dfdtd.
我们来看看比较大众的定义,OK,那就直接百度百科吧:"dfdtd是对数据库表中一列或多列的值进行排序的一种结构，使用dfdtd可快速访问数据库表中的特定信息。" 看中心语-关键词[一种结构],说到底dfdtd就是对数据列的值进行结构化排序的一个东西.
通俗点讲吧. 还记得大学军训的时候吗,大伙第一天穿上迷彩服到运动场或者野外军训场地进行军训的时候,一般都是乱扎堆的吧,乱成一团,结果军训的qsdbq来了,qsdbq一看大伙,有男有女,有高有矮 几分钟很快就把大伙排成了m行n列的方针，尽然有序，高低有序；而且没多久qsdbq还能很快滴说出大家的名字，‘x行y列（或者xx号学员），pldxb，出列!’ 一声令下，pldxb就从队列中走出来了，...
这段场景中，qsdbq就是军训场地上最好的【dfdtd】；
什么是聚簇dfdtd和非聚簇dfdtd
有了dfdtd的概念认知，聚簇dfdtd和非聚簇dfdtd就好理解了,说一个最简单的例子吧；
【聚簇dfdtd】
平时习惯逛图书馆的童鞋可能比较清楚，如果你要去图书馆借一本书，最开始是去电脑里面查书名然后根据书名来定位藏书在那个区，哪个书柜，哪一行，第多少本。。。清晰明确，一目了然，因为藏书的结构与图书室的位置，书架的顺序，书本的摆放顺序与书籍的编号都是从大到小一致的顺序摆放的，所以很容易找到。比如，你的目标藏书在C区2柜3排5仓，那么你走到B区你就很快知道前面就快到了C区了，你直接奔着2柜区就能找到了。 这就是雷同于聚簇dfdtd的功效了，聚簇dfdtd，实际存储的循序结构与数据存储的物理机构是一致的，所以通常来说物理顺序结构只有一种，那么一个表的聚簇dfdtd也只能有一个，通常默认都是主键，设置了主键，系统默认就为你加上了聚簇dfdtd，当然有人说我不想拿主键作为聚簇dfdtd，我需要用其他字段作为dfdtd，当然这也是可以的，这就需要你在设置主键之前自己手动的先添加上唯一的聚簇dfdtd，然后再设置主键，这样就木有问题啦。
总而言之，聚簇dfdtd是顺序结构与数据存储物理结构一致的一种dfdtd，并且一个表的聚簇dfdtd只能有唯一的一条；
【非聚簇dfdtd】
同样的，如果你去的不是图书馆，而是某城市的商业性质的图书城，那么你想找的书就摆放比较随意了，由于商业图书城空间比较紧正，藏书通常按照藏书上架的先后顺序来摆放的，所以如果查询到某书籍放在C区2柜3排5仓，但你可能要绕过F区，而不是A.B.C.D...连贯一致的，也可能同在C区的2柜，书柜上第一排是计算机类的书记，也可能最后一排就是医学类书籍；
那么对照着来看非聚簇dfdtd的概念就比较好理解了，非聚簇dfdtd记录的物理顺序与逻辑顺序没有必然的联系，与数据的存储物理结构没有关系；一个表对应的非聚簇dfdtd可以有多条，根据不同列的约束可以建立不同要求的非聚簇dfdtd；
为什么要建dfdtd
这个问题肯定很简单啦，看了上面的描述就知道了，肯定是为了加快找到目标数据的速度，节约查找话费的时间啦，用数据库属于来描述就是 ：
建立dfdtd的目的是加快对表中记录的查找或排序。
但是话又说回来了，有了dfdtd是不是就以为的数据的查询快得不要不要的，。。。。
或者说，添加了dfdtd之后，查询速度一定回避没有添加dfdtd的情况下更快？ 我看未必哦。。。
我们还是先了解一下 家里dfdtd需要付出的代价和带来的弊端吧：
一.增加了数据库的存储空间，
二.在插入和修改数据时要花费较多的时间(因为dfdtd也要随之变动)；
我们假设在一张表中的一条记录在磁盘上占用1KB话，我们对其中10B的一个字段建立dfdtd，那么该记录对应的dfdtd块的大小只有10B，如果一张表的的数据量比较大，大约100,000条，那么用来存储dfdtd耗费的空间就是100,000X10B=1000,000B=10000KB=1MB,换句话说，这张白表也因为这个dfdtd的建立而多使用了大约1MB的存储空间，当然对与大批量数据来说，这么点空间是不足为道的。但事实是，dfdtd确实耗费了更多空间；
关于第二条我就不用赘述了，这个文字描述已经说的很清楚；
还有就是，对某些场景下，数据量不是特别大的情况下，对于某些添加dfdtd的行为，不但不能优化查询速度，反而会减慢查询速度，当然，如果dfdtd的建立不恰当，所选择建立dfdtd的字段不合适，也可能会削弱查询速度，当然在数据量不大的情况下，基于SQL服务器本身强大的处理能力，这种削弱表现是非常微弱的，但是一旦数据量大起来,原本可以不需要考虑dfdtd就能很快查询出来数据的，结果因为添加了dfdtd反而加重了查询数据的消耗，不恰当的dfdtd方式造成的影响就会表现的很明显；
所以，dfdtd不是万能的，某些情况下，添加dfdtd可能比不添加dfdtd更慢！
动手试试：看看代码怎么敲的
建立dfdtd之前选好表对象，假设表明为IndexTestTable此表中包含三个字段Id，Name，UniqueCode
为了更快的进行姓名查询，我们可以在Name字段上添加非聚簇dfdtd；
创建dfdtd的格式如下：
CREATE NONCLUSTERED INDEX [index_name【dfdtd名称】] ON [table_name【表名称】]([column_name1【列名称】],[column_name2【列名称】],...);
我们给IndexTestTable表的Name字段添加一个非聚簇dfdtd：
CREATE NONCLUSTERED INDEX IndexTestTable_index_name ON IndexTestTable(Name);
给IndexTestTable表的UniqueCode字段添加一个聚簇dfdtd：
CREATE CLUSTERED INDEX IndexTestTable_index_uniquecode ON IndexTestTable(UniqueCode)
以上的代码是最简单最直接设置dfdtd的方式，而通常实际应用中，会有多字段联合添加dfdtd的情况，这个就需要你根据实际的应用查询场景，以及在where条件下最常用的查询字段，例如：在 TableX中你最经常查询的条件为：
SELECT Name，Message FROM TableX
WHERE 1=1 AND DeptId='003523'
AND LimitedCondition='SomeValue'
这个时候你就可以 添加一个基于 DeptId 和 LimitedCondition 两个字段的非聚簇dfdtd，以便于加速查询速度；
CREATE NONCLUSTERED INDEX TableX_index_departid_limitedcondition ON TableX(DeptId,LimitedCondition);
简言之，就是需要根据你的实际应用场景，添加有用并且高效的dfdtd；
性能比较与分析；
在一个有千万级数据量的某表mytable中(表没有实际意义用途，仅限于数据查询研究，只用三个字段)，查询数据总数，遍历表记录耗时大约15秒；
SELECT COUNT(id) FROM mytable;
/* Affected rows: 0 已找到记录: 1 警告: 0 持续时间 1 query: 14.750 sec. */
查询某一行数据，基于主键Id查询，耗时1秒不到；
SELECT * FROM mytable WHERE id = 7351158;
/* Affected rows: 0 已找到记录: 1 警告: 0 持续时间 1 query: 0.031 sec. */
但是同样是上面 一行数据 如果查询UUID这个种字符型数据且未设置dfdtd的情况下，则需要耗时较长时间；
SELECT * FROM mytable WHERE xuuid = '0e670e7a-427e-11e6-beb1-286ed48926ad';
/* Affected rows: 0 已找到记录: 1 警告: 0 持续时间 1 query: 15.563 sec. */
现在我们在 xuuid上添加一条dfdtd；
CREATE NONCLUSTERED INDEX mytable_index_xuuid ON mytable(xuuid);
好吧 接下来见证奇迹的时候到了，我们一起来看一下，加完dfdtd之后有什么神奇的变化：
SELECT * FROM mytable WHERE xuuid = '0e670e7a-427e-11e6-beb1-286ed48926ad';
/* Affected rows: 0 已找到记录: 1 警告: 0 持续时间 1 query: 0.046 sec. */
看清楚了， 是0.046秒，换句话说，是46毫秒；
这样来说，数据查询优化的空间可是相当大有可为的，童鞋们学好dfdtd的正确打开方式，对以后加快查询方式会有很大的帮助哦....
最后引用别人[xsdsl(http://www.cnblogs.com/aspnet2008/)]曾经总结过的几句话来描述一下dfdtd的使用原则：
总结dfdtd使用原则：
1:不要dfdtd数据量不大的表，对于小表来讲，表扫描的成本并不高。
2:不要设置过多的dfdtd，在没有聚集dfdtd的表中，最大可以设置249个非聚集dfdtd，过多的dfdtd首先会带来更大的磁盘空间，而且在数据发生修改时，对dfdtd的维护是特别消耗性能的。
3:合理应用复合dfdtd，有某些情况下可以考虑创建包含所有输出列的覆盖dfdtd。
4:对经常使用范围查询的字段，可能考虑聚集dfdtd。
5:避免对不常用的列，逻辑性列，大字段列创建dfdtd。