當索引鍵在表中更新時，索引更新如何工作？

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樹中另一頁的另一個插槽。原始插槽將保持空白。如果新頁面已滿，則會發生頁面拆分。這會導致父頁面發生更改，如果該頁面也已滿，則可能會發生另一個頁面拆分，以此類推。這些事件可能會導致碎片化，從而導致性能下降。