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