Sql高手请进-数据库碎片问题

Question

碎片不是很多,碎片整理用
1. 在不影响数据的情况下(不如Identity)删除聚集索引,再重建聚集索引,
   这样整理彻底. 可用dbcc showcontig(TABLE)看出扩展盘区扫描碎片为0%2. 用DBCC indexdefrag整理,不过不够彻底

Answer 1

可以用下面的语句重键所有索引
exec sp_msforeachtable "DBCC DBREINDEX ('?', '', 70)"

Answer 2

碎片是由索引引起的，下面介绍了处理碎片的方法，及方法之间的区别DBCC INDEXDEFRAG 可以对表或视图上的索引和非聚集索引进行碎片整理。DBCC INDEXDEFRAG 对索引的叶级进行碎片整理，以便页的物理顺序与叶节点从左到右的逻辑顺序相匹配，从而提高索引扫描性能。DBCC INDEXDEFRAG 还压缩索引页，并在压缩时考虑创建索引时指定的 FILLFACTOR。此压缩所产生的任何空页都将删除。有关 FILLFACTOR 的更多信息，请参见 CREATE INDEX。如果索引跨越多个文件，则 DBCC INDEXDEFRAG 一次对一个文件进行碎片整理。页不在文件之间迁移。 DBCC INDEXDEFRAG 每隔 5 分钟向用户报告预计完成的百分比。可在进程中的任一点结束 DBCC INDEXDEFRAG，任何已完成的工作都将保留。与 DBCC DBREINDEX（一般的索引生成操作）不同，DBCC INDEXDEFRAG 是联机操作。它不长期控制锁，因此不会防碍运行查询或更新。若索引的碎片相对较少，则整理该索引的速度比生成一个新索引要快，这是因为碎片整理所需的时间与碎片的数量有关。对碎片太多的索引进行整理可能要比重建花更多的时间。另外，始终对碎片整理进行完整的日志记录，与数据库恢复模型设置无关（请参见 ALTER DATABASE）。对碎片太多的索引进行整理所生成的日志记录可能比完全记录的索引创建还要多。然而，若需经常进行日志备份或如果恢复模型设置是 SIMPLE，碎片整理将作为一系列短事务执行，因此不需要大量的日志。 另外，如果两个索引在磁盘上交叉存取事务，DBCC INDEXDEFRAG 将没有作用，原因是 INDEXDEFRAG 打乱了已有的页。若要改善页的聚集，请重建索引。不支持在系统表上使用 DBCC INDEXDEFRAG。