SQLServer数据库的查询优化及分页算法(1)

　　探讨如何在有着1000万条数据的MS SQL SERVER数据库中实现快速的数据提取和数据分页。以下代码说明了我们实例中数据库的“红头文件”一表的部分数据结构：　　　　CREATE TABLE [dbo].[TGongwen] (　　--TGongwen是红头文件表名　　　　[Gid] [int] IDENTITY (1, 1) NOT NULL ,　　--本表的id号，也是主键　　　　[title] [varchar] (80) COLLATE Chinese_PRC_CI_AS NULL ,　　--红头文件的标题　　　　[fariqi] [datetime] NULL ,　　--发布日期　　　　[neibuYonghu] [varchar] (70) COLLATE Chinese_PRC_CI_AS NULL ,　　--发布用户　　　　[reader] [varchar] (900) COLLATE Chinese_PRC_CI_AS NULL ,　　　　--需要浏览的用户。每个用户中间用分隔符“,”分开　　　　) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]　　　　GO　　　　下面，我们来往数据库中添加1000万条数据：　　　　declare @i int　　　　set @i=1　　　　while @i 　　　　我们把这种目录纯粹是目录，正文纯粹是正文的排序方式称为“非聚集索引”。　　　　通过以上例子，我们可以理解到什么是“聚集索引”和“非聚集索引”。　　　　进一步引申一下，我们可以很容易的理解：每个表只能有一个聚集索引，因为目录只能按照一种方法进行排序。　　　　（二）何时使用聚集索引或非聚集索引　　　　下面的表总结了何时使用聚集索引或非聚集索引（很重要）。　　　　动作描述　　使用聚集索引　　使用非聚集索引　　　　列经常被分组排序　　应　　应　　　　返回某范围内的数据　　应　　不应　　　　一个或极少不同值　　不应　　不应　　　　小数目的不同值　　应　　不应　　　　大数目的不同值　　不应　　应　　　　频繁更新的列　　不应　　应　　　　外键列　　应　　应　　　　主键列　　应　　应　　　　频繁修改索引列　　不应　　应　　　　事实上，我们可以通过前面聚集索引和非聚集索引的定义的例子来理解上表。如：返回某范围内的数据一项。比如您的某个表有一个时间列，恰好您把聚合索引建立在了该列，这时您查询2004年1月1日至2004年10月1日之间的全部数据时，这个速度就将是很快的，因为您的这本字典正文是按日期进行排序的，聚类索引只需要找到要检索的所有数据中的开头和结尾数据即可；而不像非聚集索引，必须先查到目录中查到每一项数据对应的页码，然后再根据页码查到具体内容。　　　　（三）结合实际，谈索引使用的误区　　　　理论的目的是应用。虽然我们刚才列出了何时应使用聚集索引或非聚集索引，但在实践中以上规则却很容易被忽视或不能根据实际情况进行综合分析。下面我们将根据在实践中遇到的实际问题来谈一下索引使用的误区，以便于大家掌握索引建立的方法。　　　　1、主键就是聚集索引　　　　这种想法笔者认为是极端错误的，是对聚集索引的一种浪费。虽然SQL SERVER默认是在主键上建立聚集索引的。　　　　通常，我们会在每个表中都建立一个ID列，以区分每条数据，并且这个ID列是自动增大的，步长一般为1。我们的这个办公自动化的实例中的列Gid就是如此。此时，如果我们将这个列设为主键，SQL SERVER会将此列默认为聚集索引。这样做有好处，就是可以让您的数据在数据库中按照ID进行物理排序，但笔者认为这样做意义不大。　　　　显而易见，聚集索引的优势是很明显的，而每个表中只能有一个聚集索引的规则，这使得聚集索引变得更加珍贵。　　　　从我们前面谈到的聚集索引的定义我们可以看出，使用聚集索引的最大好处就是能够根据查询要求，迅速缩小查询范围，避免全表扫描。在实际应用中，因为ID号是自动生成的，我们并不知道每条记录的ID号，所以我们很难在实践中用ID号来进行查询。这就使让ID号这个主键作为聚集索引成为一种资源浪费。其次，让每个ID号都不同的字段作为聚集索引也不符合“大数目的不同值情况下不应建立聚合索引”规则；当然，这种情况只是针对用户经常修改记录内容，特别是索引项的时候会负作用，但对于查询速度并没有影响。　　　　在办公