索引碎片整理脚本答案

【问题标题】：index defragmentatio script索引碎片整理脚本
【发布时间】：2018-01-29 10:59:19
【问题描述】：

在运行索引维护脚本方面需要帮助。

我正在使用这个教程https://ola.hallengren.com/sql-server-index-and-statistics-maintenance.html

我下载了脚本，在我的数据库上运行它，然后我用我的数据库名称执行了一个示例。

EXECUTE dbo.IndexOptimize
@Databases = 'USER_DATABASES',
@FragmentationLow = NULL,
@FragmentationMedium = 
'INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationHigh = 'INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationLevel1 = 5,
@FragmentationLevel2 = 30,
@UpdateStatistics = 'ALL',
@OnlyModifiedStatistics = 'Y'

它贯穿始终，我希望它会改变数据库索引碎片，但它似乎没有改变任何东西。我不确定我是否没有遗漏任何东西。

谢谢。

【问题讨论】：

你确定你有索引吗？你确定它们是碎片化的吗？您的索引有多大（以页面计）？
是的，我在我的演示数据库上运行它。首先我运行我的脚本来找出索引碎片，其中有很多碎片> 50％。例如一个是 680KB 大的片段。约 87%
>>>680KB

标签： sql-server sql-server-2017

【解决方案1】：

首先要注意的是，如果您的索引少于 1000 页，那么脚本将忽略索引。这是因为 Microsoft（实际上是 Paul Randall 的）建议不要对少于 1000 页的索引进行重新排序/重建。这是因为由于索引的大小，从维护中获得的收益“通常”可以忽略不计。

其次，如果您的索引少于 8 页，那么这些页面将以混合范围存储。这也会使您的碎片读数从水中消失。

需要注意的一点是，我认为您所说的外部碎片（总碎片）仅在从磁盘读取时才是真正的问题。如果您能够将所有数据放入内存中，那么您不必担心碎片、更多统计信息维护和一致性检查。我提到一致性检查是因为人们经常运行索引维护而不是 CHECKDB。

如果您真的想了解索引维护和性能，请尝试 Brent Ozar 的 this GroupBy 会话。

【讨论】：