数据库重建索引方案

数据库重建索引方案

索引是数据库引擎中针对表(有时候也针对视图)建立的特殊数据结构，用来帮助查找和整理数据。索引的重要性体现在能够使数据库引擎快速返回查询结果。当对索引所在的基础数据表进行修改时(包括插入、删除和更新等操作)，会导致索引碎片的产生。当索引的逻辑排序和基础表或视图的物理排序不匹配时，就会产生索引碎片。随着索引碎片的不断增多，查询响应时间就会变慢，查询性能也会下降。在SQL Server 2005中，要解决这个问题，要么重新组织索引要么重新生成索引。

重新组织索引会对最外层数据页里的数据进行重新排序，并压缩索引页。重新组织的过程中不会添加任何额外的数据，所以索引可能还残留着一定程度的碎片。重新组织索引操作不会占用很多系统资源，在运行过程中外部进程也可以对该索引所在的数据表进行查询，所以可以说是联机(online)执行。

重新生成索引操作基本上删除掉目标索引并创建一个新索引，旧索引中的任何碎片都会被删除，新索引的逻辑排序将和对象的物理排序相匹配。SQL Server 2005引进了以联机方式重新生成索引的能力，这样其他进程就能够在此过程中正常访问数据表，而且也就不需要限制在非繁忙时段进行索引重新生成操作。联机重新生成索引，虽然在操作完成后旧索引会被删除，但必须确保在操作进行中有足够的可用磁盘空间来容纳正在创建的索引和之前存在的旧索引。此外，联机重新生成索引需要安装SQLServer2005的SP3补丁包，而且比一般的重新生成索引需要耗费更多的时间和资源。

以上两种方法都是SQLserver2005维护计划功能里自带的任务，可以在SQLserver2005里通过设置来实现。

另一种方法是通过DBCC DBREINDEX语句来实现数据索引重建，在SQLserver2005维护计划里建立一个作业，定期自动执行这些DBCC语句来完成对数据库指定数据表的索引重建。在执行DBREINDEX的时候客户端可以正常登陆，但是涉及到重建索引的表的操作将无法完成，因为DBREINDEX是脱机操作的。重建过程需要耗费的时间跟表的大小有关系，一般重建Reportform跟Reportitem两个表的索引需要10分钟左右的时间。

我们建议先在SQLServer2005上安装SP3的补丁，然后使用软件自带的联机重新生成索引的方法来测试，观察重新生成索引需要花费的时间，以及对服务器资源的占用情况（内存、硬盘空间等）。如果花费时间很长，占用资源很多的话再考虑用DBCC语句的方式来实现，只是在语句执行的过程中会影响业务站点的使用，需要测试具体语句执行的时间。

数据迁移的问题我们有两个方案，方案一是在SQLServer2005上建立一个维护计划，每天定时执行数据迁移的作业，将需要迁移的数据迁移到历史数据表中。原则上每天只迁移一天的数据。

方案二是采用SQLServer2005的分区功能，在服务器上建立分区文件组，把数据按照时间区间分别存放在不同的文件中，这样可以大大提高数据库的性能，实现数据库分区之后就不用再做历史数据迁移的工作了。（要实现数据库分区，院方需要在服务器上增加2块500G 的硬盘用来存放分区文件）