误区 #29:可以通过对堆建聚集索引再DROP后进行堆上的碎片整理
Nooooooooooooo!!!

对堆建聚集索引再DROP在我看来是除了收缩数据库之外最2的事了。
如果你通过sys.dm_db_index_physical_stats(或是老版本的DBCC SHOWCONTIG)看到堆上有碎片,绝对不要通过建立聚集索引再删除聚集索引来整理堆碎片。好的做法应该是建立聚集索引之后不再删除,已经有非常多的资料阐述如何选择一个理想的聚集索引键--窄,很少变动,唯一,自增。Kimberly有一篇文章对此做了一个总结:Ever-increasing clustering key - the Clustered Index Debate..........again!(注意,是基于SQL Server 2005版本),对此我也有一个例子:An example of a nasty cluster key
你也可以在SQL Server 2008中通过ALTER TABLE ... REBUILD来清除堆碎片,但这个做法和建立聚集索引后再删除同样邪恶。
如果你想问为什么我对此甚有成见?好吧,那我解释一下:非聚集索引中每一行都会指向一个RID或是聚集索引键的链接(详情请看:What Happens if I Drop a Clustered Index?),这个链接会以下面两种方式之一出现:
  • 如果非聚集索引所在的表是堆,那么这个链接就是一个RID。
  • 如果非聚集索引所在的表是聚集索引,那么这个链接就是聚集索引键。
    如果你希望对此有更多了解,请看文章底部的链接。
    因此不难看出,如果你希望将堆变为聚集索引,那么非聚集索引的所有RID就失效了,因此所有的非聚集索引都需要被重建。同样,如果删除聚集索引键,那么所有非聚集索引上存储的聚集索引键都会失效,因此也需要重建所有的非聚集索引。
    简单点说,如果你建立再删除聚集索引后,所有的非聚集索引都会被重建两次。
    如果你使用SQL Server 2008的ALTER TABLE ... REBUILD来整理堆碎片,那么同样也需要重建所有的非聚集索引,因为所有的RID都会变动。
    那么,如果对于“重建”聚集索引呢?这取决于SQL Server的版本以及你是进行rebuild索引亦或是改变索引。一个常见的误区是对表进行分区将会改变聚集索引键,但事实上不会。对于那些会引起非聚集索引重建的操作,请看如下列表:Indexes From Every Angle: What happens to non-clustered indexes when the table structure is changed?

更多相关文章

  1. 针对安卓软硬件碎片化,谷歌为何不作为?(转)
  2. Android官方入门文档[18]与其他碎片通信
  3. 2014 年 Android(安卓)碎片化报告
  4. 2014年Android碎片化报
  5. 【eoe Android特刊】第二十五期 Android(安卓)应用的终端适配
  6. Androidc学习笔记二之四大布局及碎片理解用法
  7. Ice Cream Sandwich系统将统一Android版本
  8. Android(安卓)的平台碎片化问题
  9. Android图

随机推荐

  1. Android(安卓)Studio连接真机没反应
  2. Android中由于设置的背景图片太大导致OOM
  3. android攻略
  4. [置顶] Android上实现仿IOS弹性ScrollVie
  5. android上传文件至服务器(android端+服务
  6. 创建 Cordova/Phonegap for Android 项目
  7. 总结EditText,TextView使用的点点滴滴
  8. android 如何绕过签名校验
  9. Android 字体和颜色
  10. html5 video自动播放-Android、IOS video