关于SQLServer30天误解第八天左右对在线操作的误解
Misunderstandings #8: online index operation does not lock the related index错误！
在线索引操作不如想象的好。
在线索引操作在操作开始时和操作结束时对资源有一个短暂的锁定，这会导致严重的拥塞。
在联机索引操作的开始时，将共享资源表锁添加到已排序的资源中。此表锁将继续在新索引创建和旧索引版本扫描中。
但问题是S锁将与表上的其他锁一起排队。这意味着s锁与其他锁不兼容。表上有s锁，表上的锁队列包含s锁。与S锁不兼容的这种锁也需要等待。这也意味着各种更新操作将被阻止。同样，如果表上有x锁或IX锁，s锁请求也将被阻塞。
当上述步骤完成后，S锁将被删除，但是你可以发现，这对数据更新的影响。所有的等待更新执行计划将编译期间
联机索引，其余的时间不需要在需要锁定的部分开始后锁定任何锁（大部分是指整个在线索引时间）。
在联机索引操作完成后，新成立的指数和旧的指标都需要添加一个框架修改锁（sch_m锁）来完成最后的操作。这锁可以想像为一个更强的表行锁。这种锁是不允许做任何表锁的存在时，为表不能执行计划重新编译。
堵塞问题在联机索引操作的最后阶段是堵塞问题在在线索引操作开始由船闸造成非常相似。它是不允许在桌子上做任何操作时sch_m锁继续或等待批准。另一方面，sch_m锁不能被授予当有任何读写操作的表。
在sch_m锁的最后阶段，旧的指标将执行延迟删除操作。元数据点分配给新索引的分配结构（因此索引ID保持不变）。更新了该表的版本。祝贺你，现在你有了一个全新的索引。
你可以看到，有一个潜在的巨大的阻塞问题的开头和结尾的联机索引操作。所以在联机索引操作的技术应该叫大部分时间联机索引操作，但这种称呼不能受到市场的欢迎。如果你想知道更多关于在线索引操作，请阅读白皮书：在SQL Server 2005联机索引操作。
译者注：王阳是一篇关于在线索引操作的文章非常详细，有兴趣的同学可以阅读在线索引工作，我在文章中复制了他的一篇文章，使在线索引操作步骤更加清晰。