有人问了我一个最有意思的问题:“你能禁用聚集索引么?”
对这个问题,我先是吓了一跳,因为我从未想过禁用聚集索引,因为聚集索引代表表数据,对这个最有趣问题,我立即答道:“我认为可以,但是...”
好吧,我们现在来讨论下“但是”。你禁用聚集索引,但我真的不知道SQL Server会如何反应,因此我们来试验下。
(以下代码运行在AdventureWorks2008R2数据库)
1 -- Let's disable a Clustered Index 2 ALTER INDEX PK_Person_BusinessEntityID ON Person.Person DISABLE 3 GO
哈!语句还是可以正常执行的!但是你收到很多不同的外键约束也被禁用的警告。
好,我们已经禁用了表的聚集索引,但我们也有效的禁用了表本身。我们对禁用的聚集索引运行一个简单的SELECT语句。
1 -- Let's run a SELECT statement against the disabled Clustered Index 2 SELECT * FROM Person.Person 3 GO
这下玩完了!!!查询处理器无法生成计划,我们弄坏了我们的SQL语句。
当你开始考虑它的时候,很能想到这是有道理的:我们禁用了聚集索引,也禁用了表本身!但这不应该真的有关系,因为表上有非聚集索引,也可以作为我们获取数据的路径。
我们再想下。我们是否可以通过非聚集索引来访问表数据?理论上是可以的,只要选择的非聚集索引是覆盖非聚集索引。如果你通过从聚集索引的书签查找来请求一些其它列,你还是会有大问题,因为聚集索引已经禁用。因此我们来通过查询sys.index来看下非聚集索引的状态:
1 SELECT object_id , name ,index_id ,type ,type_desc , is_disabled FROM sys.indexes WHERE object_id=OBJECT_ID('Person.Person')
哇!我们所有的的非聚集索引也被禁用了!现在根本没有方法访问我们的数据了。这是完全有道理的,因为不然的话会引入需要书签查找的巨大问题。现在我们通过禁用聚集索引已经完全把表下线了!
怎么恢复表在线呢?简单:我们需要重建我们的聚集索引:
1 -- Let's rebuild the Clustered Index 2 ALTER INDEX PK_Person_BusinessEntityID ON Person.Person REBUILD 3 GO
很简单,是不是?但当我们再次查询sys.index时,我们会看到我们的非聚集索引“还是禁用的”!
因此我们“也要”重建我们的非聚集索引,让它们恢复在线。
教训:绝不禁用表的聚集索引!
感谢关注!
原文链接: