确认索引碎片的主要SQL Server命令是DBCC SHOWCONTIG。下面这个示例代码是用来确定Pubs数据库中的Authors表的索引碎片的:
|
确定Pubs数据库中的Authors表的聚簇索引的索引碎片,可以执行下面的命令:
|
作为一个引用点,1值显示聚簇索引。2到255值显示一个具体的非聚簇索引。
确定是否重建索引的一条经验法则是看扫描密度是否低于90%。
要根据技巧1来理解我们的数据:如果注意到特定的表总是有较低的扫描密度的,那么可以考虑将填充因数和pad_index降低5%到10%以减少碎片。
随着数据的增长,会造成数据库增大和事务运行时间的增长,维护窗口每一秒都会有计数。利用我们的备份服务器或将一个最近的生产数据库备份恢复到一个开发/测试服务器,然后执行DBCC命令。这样我们就可以及时地查看数据库碎 片情况,从而维护窗口就可以只集中在重建的索引上。一旦我们有了这个数据,我们就可以执行技巧4上所列出的命令中的一个来重建碎裂的索引。然后,重新执行 DBCC SHOWCONTIG来验证索引碎片是否已经修正。这将可以验证我们的脚本,并且粗略估计生产系统所需要的时间。
技巧5:重建碎裂的索引
索引维护是一个用来保证索引最佳配置的关键。"Index rebuild options"表概括了用来维护索引的典型方法。
Index rebuild options |
|||
ID |
Description |
Recommendations |
Sample code |
1 |
执行:当系统没有用户时,当表的索引变化要求删除旧的索引并用新的索引配置替代时,当表的聚簇索引发生变化时,因为所有非聚簇索引都依赖于聚簇索引,所以它们需要重建。 |
USE PUBS GO DROP INDEX Authors.au_id_ind GO
CREATE CLUSTERED INDEX au_id_ind ON authors (au_id) GO
|
|
2 |
执行:当系统没有用户时,当表之间存在引用完整性并且需要维护时,当索引配置修改聚簇索引所需要的填充因数时,它支持一个原子事务,以保证不会丢失任何索引。 |
USE Pubs GO DBCC DBREINDEX (Authors, '', 70) GO
|
|
3 |
当系统没有用户时执行。用以清除一个索引的碎片。 |
USE Pubs GO DBCC INDEXDEFRAG (Pubs, Authors, au_id_ind GO
|
技巧6:配置数据库
与索引碎片相关的是磁盘级碎片,它是由文件删除和逻辑磁盘 文件系统重组所造成的非连续文件系统,它会降低I/O敏感进程的性能。下面的建议可以最小化磁盘级碎片:
- 为 数据库 准备专用 磁盘
- 以连续方式在 磁盘 上进行 数据库 写入
- 给大型的数据预分配相对应的 数据库 大小(如,为每个月增长1GB的100GB 数据库 多准备10GB空间)
- 不要自动增长和缩小 数据库
总结
索引碎片对高性能的数据库是至关重要的。确认有益的索引并不断维护它们将保证整个应用过程中的高性能。祝你好运!