建⽴索引的不利因素（缺点）
创建索引和维护索引要耗费时间，这种时间随着数据量的增加⽽增加。
索引需要占物理空间，除了数据表占数据空间之外，每⼀个索引还要占⼀定的物理空间，如果要建⽴聚簇索引，那么需要的空间就会更
⼤。
当对表中的数据进⾏增加、删除和修改的时候，索引也要动态的维护，这样就降低了数据的维护速度。
创建索引的准则
在经常需要搜索的列上，可以加快搜索的速度；
在作为主键的列上，强制该列的唯⼀性和组织表中数据的排列结构；
在经常⽤在连接的列上，这些列主要是⼀些外键，可以加快连接的速度；
在经常需要根据范围进⾏搜索的列上创建索引，因为索引已经排序，其指定的范围是连续的；
在经常需要排序的列上创建索引，因为索引已经排序，这样查询可以利⽤索引的排序，加快排序查询时间；
在经常使⽤在WHERE⼦句中的列上⾯创建索引，加快条件的判断速度。
对于⾮常⼩的表、⼤部分情况下简单的全表扫描⽐建⽴索引更⾼效；对于中到⼤型的表，索引就⾮常有效；但是对于特⼤型的表，建⽴
和维护索引的代价将会随之增长。这种情况下，需要⽤到⼀种技术可以直接区分出需要查询的⼀组数据，⽽不是⼀条记录⼀条记录地匹
配，例如可以使⽤分区技术。
哪些列不应该创建索引？
对于那些在查询中很少使⽤或者参考的列不应该创建索引。这是因为，既然这些列很少使⽤到，因此有索引或者⽆索引，并不能提⾼查
询速度。相反，由于增加了索引，反⽽降低了系统的维护速度和增⼤了空间需求。
对于那些只有很少数据值的列也不应该增加索引。这是因为，由于这些列的取值很少，例如⼈事表的性别列，在查询的结果中，结果集
的数据⾏占了表中数据⾏的很⼤⽐例，即需要在表中搜索的数据⾏的⽐例很⼤。增加索引，并不能明显加快检索速度。
对于那些定义为text, image和bit数据类型的列不应该增加索引。这是因为，这些列的数据量要么相当⼤，要么取值很少。
当修改性能远远⼤于检索性能时，不应该创建索引。这是因为，修改性能和检索性能是互相⽭盾的。当增加索引时，会提⾼检索性能，
但是会降低修改性能。当减少索引时，会提⾼修改性能，降低检索性能。因此，当修改性能远远⼤于检索性能时，不应该创建索引。
聚集索引和⾮聚集索引的区别
聚集索引⼀个表只能有⼀个；⽽⾮聚集索引⼀个表可以存在多个。
聚集索引存储记录是物理上连续存在；⽽⾮聚集索引是逻辑上的连续，物理存储并不连续。
聚集索引：物理存储按照索引排序（数据⾏的物理顺序与列值（⼀般是主键的那⼀列）的逻辑顺序相同）；聚集索引是⼀种索引组织形式，
索引的键值逻辑顺序决定了表数据⾏的物理存储顺序；
⾮聚集索引：物理存储不按照索引排序（索引的逻辑顺序与磁盘上⾏的物理存储顺序不同）；⾮聚集索引是普通索引，仅仅只是对数据列创
建相应的索引，不影响整个表的物理存储顺序。
聚集索引的叶节点就是数据节点。⽽⾮聚集索引的叶节点仍然是索引节点，只不过有⼀个指针指向对应的数据块。
聚集索引的约束是唯⼀性，是否要求字段也是唯⼀的呢？
不要求唯⼀。⼀般我们指定⼀个表的主键，如果这个表之前没有聚集索引，同时建⽴主键时候没有强制指定使⽤⾮聚集索引，SQL会默认在
此字段上创建⼀个聚集索引，⽽主键都是唯⼀的，所以理所当然的认为创建聚集索引的字段也需要唯⼀。聚集索引可以创建在任何⼀列你想
创建的字段上，这是从理论上讲，实际情况并不能随便指定，否则在性能上会是恶梦。
为什么聚集索引可以创建在任何⼀列上，如果此表没有主键约束，即有可能存在重复⾏数据呢？
如果未使⽤ UNIQUE 属性创建聚集索引，数据库引擎将向表⾃动添加⼀个四字节 uniqueifier 列。必要时，数据库引擎 将向⾏⾃动添加⼀
个 uniqueifier 值，使每个键唯⼀。此列和列值供内部使⽤，⽤户不能查看或访问。
