如果用户从未在其数据库上运行REBUILD或REORGANIZE,Server是否仍然以某种方式对索引进行碎片整理?
MSDN建议,如果索引碎片超过30%,建议运行REBUILD而不是REORGANIZE。多次运行REORGANIZE是否会执行与REBUILD相同的操作?
我对此很好奇,因为我有一个客户端,它的索引非常分散。他们每个周末都会针对这个索引运行REORGANIZE,随着时间的推移,他们的索引似乎变得支离破碎。
这有道理吗?
发布于 2012-01-11 20:02:12
不,没有自动神奇的索引碎片整理。如果有碎片,则需要REBUILD或REORGANIZE。
重新组织索引,通过物理地重新排序页来分解索引的叶级,以匹配逻辑顺序。锁持续时间短,将导致查询阻塞最少。
重建删除一个索引并构建一个新的索引。使用Enterprise,如果索引不包括任何LOB类型,这可以作为一个在线操作来完成。对于标准版本或LOB类型存在的地方,它将导致阻塞。有关如何与用户操作同时进行联机重建的说明,请参见联机索引操作如何工作。
重组vs重构建议大致是通过重组来整理碎片所需的工作量与重建所需的工作量相媲美的阈值,即在>30%的分段状态下,完成重组所需的资源和时间要比重建多。
多次重新组织运行不会进一步对索引进行碎片整理。
发布于 2012-01-11 19:58:05
如果用户从未在数据库上运行重新构建或重新组织,SqlServer引擎会对索引进行碎片化吗?
不是的。
运行重新组织是否会多次执行与重新构建相同的操作?
也没有。
REORGANIZE根据索引规范重新排序叶页(保存实际索引数据的页面)。也可以合并页和空白页,但不会分配新页面,也不会重新构建btree结构和状态。
一个REBUILD删除旧的索引,从零开始。这将更新所有b-树结构,删除不必要的空闲空间,并将碎片设置为0(或尽可能保持数据库中空闲页面的连续性)。
发布于 2012-01-11 19:55:56
没有SQL Server不进行任何类型的自动维护。
在第一次成功运行之后,多次运行REORGANIZE将没有任何效果(忽略自被重新组织后修改的页面,或者在第一次尝试时无法锁定并因此跳过的页面)。
它将无序页面转换为正确的顺序,因此一旦它这样做了,并且它们都处于正确的顺序中,额外的运行将不会产生任何影响。它不能消除由于非连续分配而产生的碎片。为此你需要重建。
https://dba.stackexchange.com/questions/10535
复制相似问题