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