当索引键在表中更新时，索引更新如何工作？

Question

我以前认为，当我更新表中的索引列时，同时索引也被更新。但在我的一次采访中，采访者强调，这种方式并不奏效。对于基表中的任何更新，索引将重建/重新组织。虽然我很确定这不会发生，因为这两个操作都非常昂贵，但仍然想要与专家的观点保持一致。

在想到这件事时，还有一件事出现在我的脑海里。假设我有索引列值1-1000。因此，按照B-Tree结构，假设值为999，将自上而下地排列在最右侧的节点上。现在，如果将此列从999更新为2，则需要进行大量混洗才能在索引B-Tree中调整此值。在基表更新后，如果索引重建/重新组织不会发生，将如何处理。

Answer 1

我以前认为，当我更新表中的索引列时， 同时索引也被更新。

是的，的确如此。至于删除和插入。

其他索引系统可能工作方式不同，需要逐步更新或重新构建与索引数据完全分开的索引系统。这可能令人困惑。

统计信息需要单独更新。 （请参阅此组中的其他活跃讨论。）

对于基表中的任何更新，索引都将重建/重组。

不，但如果SQL Server无法适应它的物理位置中的节点，可能会发生分页。或者当某个关键值发生变化时，可能会发生单个心理行移动。

两者都可能导致碎片。太多碎片可能会导致性能问题。这就是为什么DBA认为有必要通过在适当的时候重建或重组索引来减少碎片化。

说我有索引列值1-1000。因此，按照B-Tree结构，假设值为999，将自上而下地排列在最右侧的节点上。现在，如果将此列从999更新为2，则需要进行大量混洗才能在索引B-Tree中调整此值。在基表更新后，如果索引重建/重新组织不会发生，将如何处理。

只有已更改的行移动到B树中另一页的另一个插槽。原始插槽将保持空白。如果新页面已满，则会发生页面拆分。这会导致父页面发生更改，如果该页面也已满，则可能会发生另一个页面拆分，以此类推。这些事件可能会导致碎片化，从而导致性能下降。