SQL Server誤區30日談 第8天 有關對索引進行線上操作的誤區

誤區 #8: 線上索引操作不會使得相關的索引加鎖

錯誤！

線上索引操作並不是想象的那麼美好。

線上索引操作會在操作開始時和操作結束時對資源上短暫的鎖。這有可能導致嚴重的阻塞問題。

線上索引操作開始時,會在被整理的資源上加一個共用的表鎖,這個表鎖在會在新的索引建立時、老索引進行版本掃描時一直持續。

但問題是，這個S鎖會和表上的其它鎖排成鎖隊列。這也就是意味著和S鎖不相容的其它鎖在表上存在S鎖或是表上的鎖隊列存在中包含S鎖時，這類和S鎖不相容的鎖操作也需要等待。這也意味著各種更新操作會被阻塞。同樣，如果表上存在X鎖或是IX鎖時，S鎖請求也會被阻塞。

上述步驟完成後，S鎖會被去掉，但你可以發現這已經對資料更新產生了影響。這期間還會造成所有等待的更新操作的執行計畫被重新編譯

線上索引整理在開始需要加鎖的部分完成後，剩下的大部分時間是不需要任何鎖的。（這個大部分指的是整個線上索引整理的大部分時間）

當線上索引操作完成後，建立立的索引和老的索引上面都需要加一個構架修改鎖（SCH_M鎖）來完成最終操作。這個鎖可以想象成一個更強的表級排它鎖。這個鎖存在期間不允許對錶做任何操作，針對錶的執行計畫也不能重編譯。

線上索引操作最終階段的阻塞問題和線上索引操作開始時由S鎖造成的阻塞問題非常類似-在SCH_M鎖持續或者等待被授予期間，不允許對錶進行任何操作。反之，表中存在任何讀寫操作時，SCH_M鎖也不能被授予。

在最終階段的SCH_M鎖持續期間，舊的索引會被執行延遲DROP操作，中繼資料所指向的分配結構指向新的索引（所以index id不變）,表的版本被更新，恭喜，現在開始你已經擁有了一個全新的索引。

如你所見，線上索引操作的開始和結束階段潛在存在著巨大的阻塞問題。所以技術上對線上索引操作應該稱為“大部分時間線上索引操作”，但這種叫法可不會受到市場的歡迎。如果你想對線上索引操作瞭解更多，請閱讀白皮書:Online Indexing Operations in SQL Server 2005。

譯者注:汪洋有一篇關於線上索引操作非常詳細的文章，有興趣的同學可以閱讀: 聯機索引的工作方式 ,下面我摘抄他文章中的一個圖片來讓線上索引操作的步驟更加清晰。