SQL Server誤區30日談 第8天 有關對索引停止在線操作的誤區。本站提示廣大學習愛好者：（SQL Server誤區30日談 第8天 有關對索引停止在線操作的誤區）文章只能為提供參考，不一定能成為您想要的結果。以下是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。
譯者注:汪洋有一篇關於在線索引操作異常具體的文章，有興致的同窗可以浏覽: 聯機索引的任務方法 ,上面我摘抄他文章中的一個圖片來讓在線索引操作的步調加倍清楚。
