SQL Server誤區(qū)30日談 第8天 有關(guān)對索引進(jìn)行在線操作的誤區(qū)

誤區(qū) #8: 在線索引操作不會使得相關(guān)的索引加鎖

錯誤！

    在線索引操作并不是想象的那么美好。

    在線索引操作會在操作開始時和操作結(jié)束時對資源上短暫的鎖。這有可能導(dǎo)致嚴(yán)重的阻塞問題。

    在線索引操作開始時,會在被整理的資源上加一個共享的表鎖,這個表鎖在會在新的索引創(chuàng)建時、老索引進(jìn)行版本掃描時一直持續(xù)。

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

    上述步驟完成后，S鎖會被去掉，但你可以發(fā)現(xiàn)這已經(jīng)對數(shù)據(jù)更新產(chǎn)生了影響。這期間還會造成所有等待的更新操作的執(zhí)行計劃被重新編譯

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

    當(dāng)在線索引操作完成后，新建立的索引和老的索引上面都需要加一個構(gòu)架修改鎖（SCH_M鎖）來完成最終操作。這個鎖可以想象成一個更強(qiáng)的表級排它鎖。這個鎖存在期間不允許對表做任何操作，針對表的執(zhí)行計劃也不能重編譯。

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

    在最終階段的SCH_M鎖持續(xù)期間，舊的索引會被執(zhí)行延遲DROP操作，元數(shù)據(jù)所指向的分配結(jié)構(gòu)指向新的索引（所以index id不變）,表的版本被更新，恭喜，現(xiàn)在開始你已經(jīng)擁有了一個全新的索引。

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

    譯者注:汪洋有一篇關(guān)于在線索引操作非常詳細(xì)的文章，有興趣的同學(xué)可以閱讀: 聯(lián)機(jī)索引的工作方式 ,下面我摘抄他文章中的一個圖片來讓在線索引操作的步驟更加清晰。