提高SQLServer速度来组织索引片段

数据库表A有十万条记录，查询速度已经可以使用，但在导入一千个数据之后，问题就出现了。当选定的数据位于原始的十万个记录之间时，速度很快，但是当选定的数据在这一千个数据之间时，速度变慢。

凭经验，这是索引碎片问题。检查索引碎片dbcc showcontig（表），得到以下结果：

dbcc showcontig是扫描the'a'table…
表：A（884198200）；索引ID：1，数据库编号：13
已执行表级扫描。
扫描的页面数：3127 .........：…
扫描扩展盘区.........数量：403
-扩展磁盘区域中的交换机数量…
-每个扩展磁盘区域的平均页数……：……7.8
扫描密度{最佳值：实际值} ......：…：24.20% 391:1616 } {
逻辑扫描碎片.........：：68.02%…
在扩展盘区.........扫描碎片：…：38.46%
-每页平均可用字节数……：……2073.2
-平均页面密度（完整）……：74.39%
DBCC完成。如果DBCC输出的错误信息，请与系统管理员联系。
可以看出，扩展磁盘区域的逻辑扫描片段和扫描片段非常大，需要对索引片段进行处理。

一般来说，有两种方法可以解决它们。一是使用DBCC indexdefrag到索引碎片排序，和两个是使用DBCC DBREINDEX重建索引。两各有自己的优点和缺点。微软原来叫如下：
DBCC indexdefrag命令是在线的，所以指数是唯一可用的只有当命令运行。你可以中断操作没有完成的工作。这种方法的缺点是，去除或重新创建操作是有效的没有聚集索引在数据重组。

聚集索引的再创作将重新组织数据，其结果是填充数据页，可以配置使用FILLFACTOR选项的填充度。这种方法的缺点是，该指数是去除/再创造周期中离线，和操作是一个原子的水平。如果中断创建索引，索引将不会重新创建。

也就是说，为了获得好的结果或使用重建索引，您决定重建索引。
DBCC DBREINDEX（表、索引名称、填充因子）
第一个参数可以是表名，也可以是表ID。
第二个参数，如果是，表示影响表的所有索引。
第三参数、填充因子、数据的索引页填充度。如果是100，这意味着每一个页面都填满，选择效率最高的当时，但后来，如果我们要插入索引，我们要把所有的页面的背后，这是低效的。如果是0，这意味着使用以前的填充因子值。

DBCC DBREINDEX（一，，100）
快速检查查询的速度。