索引的优点是不言而喻的，但天下没有免费的午餐，使用索引同样也是是付出一定的代价的：创建索引和维护索引都需要消耗一定的时间和资源的，如当建有索引的表中的纪录有增、删、改的操作时，数据库要对索引进行重新调整，虽然这个工作是由数据自动完成的，但它还是要消耗服务器的资源的，当表的数据越多，这个消耗也就越多；而且索引是数据库中实际存在的对象，所以每个索引也会占用一定的物理空间。这样索引多了，不但会占用大量的物理空间，也是影响到数据库的运行性能。
可见，要通过索引来提高系统/数据库的性能，就要找到的一个临界点。
建立索引常用的规则如下：
创建索引
- 表的主键、外键必须有索引；
定义有主键的索引列，一定要为其建立索引。因为主键可以加速定位到表中的某一行。结合索引的作用，可以使得查询的速度加倍，并且可保存记录的维护一性。
另外，若要使得某个字段的值唯一，可以通过两种索引方式实现。一种就是主键索引。还有一种就是唯一索引，利用UNIQUE关键字指定字段内容的唯一性。这两种方式都会在表中的指定列上自动创建唯一索引（针对使用MS SQL SERVER 设计器，在使用工具来维护数据库时如：使用PD来建模的时间设置主键是不会自动创建为主键创建唯一索引的，甚至都不会创建索引）。这两种方式的结果没有明显的区别。查询优化器不会区分到底是哪种方式建立的唯一性索引，而且他们进行数据查询的方式也是相同的。
若某张表中的数据列定义有外键，则最好也要为这个字段建立索引。因为外键的主要作用就在于表与表之间的连接查询。若在外键上建立索引，可以加速表与表之间的连接查询。而且，记录越多，其效果越加明显。
所以，当表中有外键或者主键的时候，就最好为其建立索引。通过索引，可以强化主键与外键的作用，提高数据库的性能 - 数据量超过300的表应该有索引；
- 经常与其他表进行连接的表，在连接字段上应该建立索引；
经常出现在Where子句中的字段，特别是大表的字段，应该建立索引；
对于这些经常用在Where子句中的数据列，将索引建立在Where子句的集合过程中，对于需要加速或者频繁检索的数据列，可以让这些经常参与查询的数据列按照索引的排序进行查询，以加快查询的时间。 - 索引应该建在选择性高（重复值不多）的字段上；
- 对于按范围查询的列，最好建立索引。
对于这些需要在指定范围内快速或者频繁查询的数据列，需要为其建立索引。因为索引已经排序，其保存的时候指定的范围是连续的，查询可以利用索引的排序，加快查询速度。若采用范围查询的话，最好能利用TOP关键字来限制一次查询的结果。如第一次按顺序只显示前面的500条记录等等。把TOP关键字跟范围一起使用，可以大大的提高查询的效率
不要创建索引
- 对于查询中很少涉及的列或者重复值比较多的列，不要建立索引。
在查询的时候，如果我们不按某个字段去查询，则在这个字段上建立索引也是浪费。此时，即使在这个字段上建立索引，也不能够提高查询的速度。相反，增加了系统维护时间和占用了系统空间。另外，有些字段重复值比较多。如性别字段主要就是“男”、“女”;职位字段中也是有限的几个内容。此时，在这些字段上添加索引也不会显著的增加查询速度，减少用户响应时间。相反，因为需要占用空间，反而会降低数据库的整体性能。 - 虽然可能需要按范围来进行查询，但是，若这个范围查询条件利用的不多的情况下，最好不好采用索引
如在员工信息表中，可能需要查询2008年3月份以前入职的员工明细，要为他们增加福利。但是，由于表中记录不多，而且，也很少进行类似的查询。若在这个字段建立索引，虽然无伤大雅，但是很明显，索引所获得的收益要低于其成本支出。有点得不偿失。 - 频繁进行数据操作的表，不要建立太多的索引；
因为每数据操作数据库都会维护索引 - 对于一些特殊的数据类型，不要建立索引
在表中，有些字段比较特殊。如文本字段(TXT)、图像类型字段(IMAGE)等等。如果表中的字段属于这些数据类型，则最好不要为其建立索引。因为这些字段有一些共同的特点。如长度不确定，要么很长，几个字符;要么就是空字符串。如文本数据类型常在应用系统的数据库表中用来做备注的数据类型。有时候备注很长，但有时候又没有数据。若这种类型的字段上建立索引，那根本起不了作用。相反，还增加了系统的负担。
但是，也有特殊的情况。如有时候，在ERP系统中，有产品信息这个表，其中有个产品规格这个字段。有时候，其长度可能长达5000个字符。此时，只有文本型的数据类型可以容纳这么大的数据量。而且，在查询的时候，用户又喜欢通过规格这个参数来查询产品信息。此时，若不为这个字段建立索引的话，则查询的速度会很慢。遇到这种情况时，只有牺牲一点系统资源，为其建立索引。
其它注意事项
- 删除无用的索引，避免对执行计划造成负面影响；
- 复合索引的建立需要进行仔细分析；尽量考虑用单字段索引代替：
- 正确选择复合索引中的主列字段，一般是选择性较好的字段；
- 复合索引的几个字段是否经常同时以AND方式出现在Where子句中？单字段查询是否极少甚至没有？如果是，则可以建立复合索引；否则考虑单字段索引；
- 如果复合索引中包含的字段经常单独出现在Where子句中，则分解为多个单字段索引；
- 如果复合索引所包含的字段超过3个，那么仔细考虑其必要性，考虑减少复合的字段；
- 如果既有单字段索引，又有这几个字段上的复合索引，一般可以删除复合索引；
聚集索引与非聚集索引
首先看看网上解释聚集索引与非聚集索引的一个举例：
汉语字典的正文本身就是一个聚集索引。比如，我们要查“安”字，就会很自然地翻开字典的前几页，因为“安”的拼音是“an”，而按照拼音排序汉字的字典是以英文字母“a”开头并以“z”结尾的，那么“安”字就自然地排在字典的前部。如果您翻完了所有以“a”开头的部分仍然找不到这个字，那么就说明您的字典中没有这个字；同样的，如果查“张”字，那您也会将您的字典翻到最后部分，因为“张”的拼音是“zhang”。也就是说，字典的正文部分本身就是一个目录，您不需要再去查其他目录来找到您需要找的内容。正文内容本身就是一种按照一定规则排列的目录称为“聚集索引”。
如果您认识某个字，您可以快速地从自动中查到这个字。但您也可能会遇到您不认识的字，不知道它的发音，这时候，您就不能按照刚才的方法找到您要查的字，而需要去根据“偏旁部首”查到您要找的字，然后根据这个字后的页码直接翻到某页来找到您要找的字。但您结合“部首目录”和“检字表”而查到的字的排序并不是真正的正文的排序方法，比如您查“张”字，我们可以看到在查部首之后的检字表中“张”的页码是672页，检字表中“张”的上面是“驰”字，但页码却是63页，“张”的下面是“弩”字，页面是390页。很显然，这些字并不是真正的分别位于“张”字的上下方，现在您看到的连续的“驰、张、弩”三字实际上就是他们在非聚集索引中的排序，是字典正文中的字在非聚集索引中的映射。我们可以通过这种方式来找到您所需要的字，但它需要两个过程，先找到目录中的结果，然后再翻到您所需要的页码。
我们把这种目录纯粹是目录，正文纯粹是正文的排序方式称为“非聚集索引”。
每个表只能有一个聚集索引，因为目录只能按照一种方法进行排序
- 用聚合索引比用不是聚合索引的主键速度快
- 用聚合索引比用一般的主键作order by时速度快，特别是在小数据量情况下
- 事实上，如果数据量很小的话，用聚集索引作为排序列要比使用非聚集索引速度快得明显的多；而数据量如果很大的话，如10万以上，则二者的速度差别不明显。
- 使用聚合索引内的时间段，搜索时间会按数据占整个数据表的百分比成比例减少，而无论聚合索引使用了多少个
- 日期列不会因为有分秒的输入而减慢查询速度
聚集索引有两个最大的优势：
- 以最快的速度缩小查询范围。
- 以最快的速度进行字段排序。
聚集索引的建立可以说是实现“查询优化”和“高效分页”的最关键因素。但要既使聚集索引列既符合查询列的需要，又符合排序列的需要，这通常是一个矛盾
聚集索引是非常的重要和珍贵，所以一定要将聚集索引建立在：
1、最频繁使用的、用以缩小查询范围的字段上；
2、最频繁使用的、需要排序的字段上。
总之，索引就好像一把双刃剑，即可以提高数据库的性能，也可能对数据库的性能起到反面作用。作为数据库管理员，要有这个能力判断在合适的时间、合适的业务、合适的字段上建立合适的索引。以上，只是对建立索引的一些基本规律，但是，是否需要遵循，还是需要根据项目的实际情况，做出合理的选择。