pau*_*ulH 5 index sql-server-2008-r2
Microsoft 建议不要费心重建少于 1,000 页的索引（从内存中我认为这是因为它们太小以至于它们将被保存在 RAM 中）。
如果我不重建它们，那么它们将变得非常支离破碎。在那种情况下，拥有它们有什么意义吗？我正在想象一个电话簿，其中每个条目都位于错误的位置 - 这将毫无用处！
为了澄清起见，我主要谈论的是非聚集索引，但我很想知道聚集索引的答案是否会有所不同。
这个问题的答案表明索引可以帮助避免行锁背后的阻塞问题，这就是为什么索引在正确并适用于 SQL Server 的情况下仍然有用的原因。
Rem*_*anu 15
仅仅因为索引不需要重建并不意味着它没有用。一个 99999% 的碎片索引在查找键时仍然比堆好 9999 倍。碎片化的负面影响在流行的 DBA 文化中被严重、严重、严重、严重高估。
锁定是一个有效的点（没有索引，所有读写操作都保证会发生冲突），但不是唯一的。即使数据是只读的，所以锁定永远不是问题，它仍然需要一个索引来进行搜索和范围扫描操作。
我在想象一个电话簿，每个条目都在错误的地方
这是对碎片化及其影响的一种非常误导的解释。一个支离破碎的电话簿仍然按顺序排列所有条目。查找一个条目仍然需要翻 2-3 页，它会是这样的：
所以是的，你来回翻转 2-3 次。碎片化的电话簿也可能每一页都是半空的，所以它的重量是新生成的电话簿的两倍。
与堆比较：
真正不需要索引的唯一数据/工作负载是列存储/数据仓库。列存储访问和处理是完全不同的，并且可以在没有索引的情况下逃脱，因为预计每个查询无论如何都会扫描所有数据。段消除、每列 IO 和其他力量有助于保持这些始终端到端的扫描的竞争力。