系统性能的提升之二--"聚集索引"的建立

以前对数据库也有过一段时间的研究，对数据库的物理存储机制也有所了解，刚看了freedk 写的《SQL Server 索引结构及其使用》受益非浅，我也真的意识到，数据库索引对系统性能的重要性。
在我的传统观念中，主键一般是应该设为聚集索引的，但现在有了新的认识，主键主要意义在于“唯一标识记录”关于主键的设计我也不再详述，可以参照我的《数据库主键设计之思考 》，而索引主要是“提高数据库性能”，尤其是“聚集索引”。
而现在我会注重数据库索引的建立，最关键的就是聚集索引，“聚集索引”与“非聚集索引”的理解很简单：“聚集索引”就是物理上的排列方式，而“非聚集索引”是使用索引表（相当于书的目录），使用索引之所以能提高性能，也就是“避免全表扫描”。
因此一个表只能有一个“聚集索引”，因为在物理上，不可能会有“两种”物理存放方式吧。也真是如此“聚集索引”对查询性能的影响最大，所以要非常注意“聚集索引”的建立，我目前意识到、也是Freedk所推荐的“单据日期”作为聚集索引，我说的“单据日期”是指日常业务性的记录，一般都是会有一个日期字段的，而80%查询中都会用到此"日期字段",而且把它放在Where的第一个效果最佳，因为会在指定的区域内进行其他条件的查询，范围少了很多很多，性能效果提高明显。
至于其他的索引，这只要根据业务的需要，对于一些会进行查询的字段进行一定的索引，也就是尽可能的“避免全表扫描”就可以提高系统性能。当然过多的索引也会引起系统负担，想想要建那么多“目录”自然会增加负担了。
还有“聚集索引”由于是物理存储的，性能上固然是提高了，但对于插入与删除，会引起数据的“移动”（在中间插入一条记录，会引起后半部分记录的后移），当然数据库有自己的存储机制，会采用“页”来进行分块存储，可以避免一定的“移动”，所以“聚集索引”最好是在“大部分”情况下可以“递增”，我们目前采用的“单据日期”也刚好是符合这个条件的。

评论：

自增长ID作为聚集索引也比较合适吧，一般数据表中"单据日期"和ID增长方向是一样的。
聚集索引的设计一般是放在最常查询结果集的限定字段所在的索引在

如果自增ID和日期字段的限定范围一致（常见的如论坛数据）
则亦可以放在自增ID所在索引上

一般来说　单据的ID和日期的限定也是一致的（除非像使用GUID做主键这种情况就不同了），所以用单据ID和单据日期做聚集索引效果差不多

聚集ID的好处就是可以缩小读取以聚集字段连续的结果集所需的页面数，坏处是导致其它索引无法直接取到实际数据，而是先定位聚集索引的指针再去取实际数据

看了上面的留言，我发现大家跟我起初的想法是差不多的，但自增ID不宜作为“聚集索引”的原因也就是不能缩小结果集搜索范围，所以在日常用的“单据日期”查询中，无法体现出高性能的查询效果，而对于主键ID，建立一般索引就可以了，因为通过主键ID搜索的一般都是定位一条记录的，没有“锁定范围”这样的性能效果。其实大家应该好好看了我的参考文章再发表留言，可能你的观点已经被改变了。。
参考文章很久以前我就看过了　自增ID的话本身就和日期字段一样有序　这样对于页面IO的限定照样是有效的　一般来说单据日期的排列和自增ID是一样的　比如说1月到4月的单据　那么自增ID也会在1~400之间　这样两者限定效果完全一样　而要查询的高效　只是说单据日期的索引　在自增ID上建聚集索引不等于说在日期字段上不建索引　
@progame :
对了，就是因为方向是一致的，所以“单据日期”符合了建聚集索引的条件了。而在“单据日期”上建了“聚集索引”比“不建聚集索引”性能提高很多很多啊。所以说要在“单据日期”上建聚集索引啊。
完全符合我的意思！！
// 但自增ID不宜作为“聚集索引”的原因也就是不能缩小结果集搜索范围

这句话是不对的　很多情况下　自增ID是可以做聚集索引的
用日期字段做聚集索引并没有错　我没有否定你的这种说法　只是说用自增ID做聚集索引同样可以
@progame :
OK，赞同，ID其实也可以做聚集索引，只是没有“日期”来的好，因为一个表只能有一个“聚集索引”，所以基本上应该采用“日期”。
我赞同在单据日期上建聚集索引的方法，因为ID在实际应用中用来查询的情况很少，建在单据日期上很容易将查询范围锁定在一个小的块。另外，问一个问题：如果有不同类型的单据（以单据编号区别），查询是大多是查某段时间某类单据的，是不是应该在单据日期和单据编号两个列上建聚集索引？我赞同在单据日期上建聚集索引的方法，因为ID在实际应用中用来查询的情况很少，建在单据日期上很容易将查询范围锁定在一个小的块。另外，问一个问题：如果有不同类型的单据（以单据编号区别），查询是大多是查某段时间某类单据的，是不是应该在单据日期和单据编号两个列上建聚集索引？