整理指定的表或视图的聚集索引和辅助索引碎片。
DBCC INDEXDEFRAG
( { database_name | database_id | 0 }
, { table_name | table_id | 'view_name' | view_id }
, { index_name | index_id }
) [ WITH NO_INFOMSGS ]
database_name | database_id | 0
是对其索引进行碎片整理的数据库。数据库名称必须符合标识符的规则。有关更多信息，请参见使用标识符。如果指定 0，则使用当前数据库。
table_name | table_id | 'view_name' | view_id
是对其索引进行碎片整理的表或视图。表名和视图名称必须符合标识符规则。
index_name | index_id
是要进行碎片整理的索引。索引名必须符合标识符的规则。
WITH NO_INFOMSGS
禁止显示所有信息性消息（具有从 0 到 10 的严重级别）。
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。
如果没有指定 WITH NO_INFOMSGS，DBCC INDEXDEFRAG 将返回以下结果集（值可能会有变化）：
Pages Scanned Pages Moved Pages Removed ------------- ----------- ------------- 359 346 8
(1 row(s) affected) DBCC execution completed. If DBCC printed error messages, contact your system administrator.
DBCC INDEXDEFRAG 权限默认授予 sysadmin 固定服务器角色或 db_owner 和 db_ddladmin 固定数据库角色的成员以及表的所有者且不可转让。
DBCC INDEXDEFRAG (Northwind, Orders, CustomersOrders) GO