SQL Server中的聚簇索引

Question

我知道當我們在SQL Server中使用其主鍵創建表時，會自動創建聚簇索引。 但是，如果我從該表中刪除一行，那么與該行相關的聚集索引是否仍然保留在索引表中，還是會自動刪除？ 如果沒有自動刪除，我是否必須創建一個作業來重建和重組索引？ （對於mysql，oracle等是一樣的嗎？）

Answer 1

我知道當我們在sqlserver中使用其主鍵創建表時，會自動創建聚簇索引。

僅當它是默認選項或者將clustered指定為關鍵字時才會出現這種情況。 主鍵也可以是非聚簇索引。

但是，如果我從該表中刪除一行，那么與該行相關的聚集索引是否仍然保留在索引表中，還是會自動刪除？

如果它確實是聚簇索引，那么索引就是表數據。 如果從表中刪除某些內容，它就會消失。 有一些內部工作，例如ghost記錄，但是數據已經消失（從應用程序的角度來看）。

如果沒有自動刪除，我是否必須創建一個作業來重建和重組索引？

也就是說，還有其他后台任務處理某些“隱藏”功能。 最終，當碎片（內部或外部）開始成為問題時，您將需要重新組織或重建索引。 這將取決於其他變量，包括表結構，訪問等。

（對於mysql，oracle等是一樣的嗎？）

問題是標記為SQL Server，所以我正在回答SQL Server標記。 對於一篇文章來說，這是一個非常廣泛的問題。

Answer 2

Oracle或MySQL的默認值不同。 每個數據庫都有自己的默認值及其特定功能。 有些人甚至使用相同的術語來表達不同的含義。

Oracle不默認為聚簇索引，而在Oracle中，等效的是索引組織表。 在Oracle中，CLUSTER的定義是一種結構，它可以存儲2個或更多個表並對它們進行相同的排序。

如果沒有自動刪除，我是否必須創建一個作業來重建和重組索引？

重建索引的第一條規則 - 衡量，衡量，衡量。 證明重建是有益的，否則不要再費心去做，除非事情發生變化。

簡單刪除（或千位）不是重建索引的自動原因。

如果要重建索引，則應該知道（1）前后訪問時間之前和之后的數據塊數（2）。

作為一般慣例，關於索引重建有很多錯誤信息和迷信。 您引用的索引是B樹結構。 這些設計為可擴展的O（log N）訪問。 沒有證據表明默認情況下必須重組索引。 每個指數都是它自己的動物。 B樹指數在一段時間后達到停滯（平衡）點，當你重建它們時，你壓縮它們（一件好事），但它們最終會回到那個停滯點。 除非我發現其中一個的性能/ IO問題，否則我會根據具體情況手動完成。

重建的兩大好處：

1. 更密集地將數據打包到更少的塊中，從而改善了緩存和IO。
2. 按累積的實際數據重新排序非聚集索引。 如果您的訪問模式始終是順序的（包括插入），那么這通常不是問題，將對這些塊進行排序。

Oracle和SQL Server是很棒的技術。 沒有證據重建索引對專業DBA沒有好處。