我最大的一個熱點問題是關于收縮資料檔案，雖然在微軟的時候，我自己寫了相關收縮資料檔案代碼，我再也沒有機會去重寫它，讓它操作起來更友善。我真的不喜歡收縮。
收縮資料檔案應該執行得甚至更少。這就是為什麼——資料檔案收縮導緻産生了大量索引碎片，讓我用一個簡單并且你可以運作的腳步來示範。下面的腳本将會建立
一個資料檔案，建立一個10mb大小的“filler”表，一個10mb大小的“production”聚簇索引，然後分析建立的聚集索引的碎片情況。
code snippet
use [master];
go
if databasepropertyex(n'dbmaint2008', n'version') is not null
drop database [dbmaint2008];
create database dbmaint2008;
use [dbmaint2008];
set nocount on;
-- create the 10mb filler table at the 'front' of the data file
create table [fillertable](
[c1] int identity,
[c2] char (8000) default 'filler');
-- fill up the filler table
insert into [fillertable] default values;
go 1280
-- create the production table, which will be 'after' the filler table in the data file
create table [prodtable](
[c2] char (8000) default 'production');
create clustered index [prod_cl] on [prodtable]([c1]);
insert into [prodtable] default values;
-- check the fragmentation of the production table
select
[avg_fragmentation_in_percent]
from sys.dm_db_index_physical_stats(
db_id(n'dbmaint2008'), object_id(n'prodtable'), 1, null, 'limited');
執行結果如下
聚集索引的邏輯碎片在收縮資料檔案前大約接近0.4%。[但是我測試結果是0.54%，如上圖所示,不過也算是接近0.4%]
現在我删除filter表，運作收縮資料檔案指令後，重新分析聚集索引的碎片化。
sql code two
-- drop the filler table, creating 10mb of free space at the 'front' of the data file
drop table [fillertable];
-- shrink the database
dbcc shrinkdatabase([dbmaint2008]);
-- check the index fragmentation again
下面是我的執行結果，作者執行結果，請看原文：
原文：
wow! after the
shrink, the logical fragmentation is almost 100%. the shrink operation
*completely* fragmented the index, removing any chance of efficient
range scans on it by ensuring the all range-scan readahead i/os will be
single-page i/os.
譯文：
哇，真是恐怖！資料檔案收縮後，索引的邏輯碎片幾乎接近100%，收縮資料檔案導緻了索引的完全碎片化。消除了任何關于它的有效範圍掃描的機會，確定所有執行提前讀範圍掃描的 i/o 在單頁的 i/o操作
為什麼會這樣呢？ 當單個資料檔案收縮操作一次後，它會用gam位圖索引找出資料檔案中配置設定最高的頁，然後盡可能的向前移動到檔案能夠移動的地方，就這樣子，在上面的例子中，它完全反轉了聚集索引，讓它從非碎片化到完全碎片化。
同樣的代碼用于dbcc
shrinkfile， dbcc
shrinkdatabase，以及自動收縮，他們同樣糟糕，就像索引的碎片化，資料檔案的收縮同樣産生了大量的i/o操作，耗費大量的cpu資源，并且
生成了*load*事務日志，因為任何操作都會全部記錄下來。
資料檔案收縮決不能作為定期維護的一部分，
你決不能啟用“自動收縮”屬性，我嘗試把它從sql 2005和sql
2008産品中移除，它還存在的唯一原因是為了更好的向前相容，不要掉入這樣的陷阱：建立一個維護計劃，重新生成所有索引，然後嘗試回收重建索引耗費的空
間采取收縮資料檔案 — — 這就是你做的生成了大量事務日志，但實質沒有提高性能的零和遊戲。
是以，你為什麼要運作一個收縮呢，？舉例來說，如果你把一個相當大的資料庫删除了相當大的比例，該資料庫不太可能增長，或者你需要轉移一個資料庫檔案前先清空資料檔案？
我很想推薦的方法如下：
建立一個新的檔案組
将所有受影響的表和索引移動到一個新的檔案組用create index ... with (drop_existing=on)的腳本，在移動表的同時，删除表中的碎片。
删掉那些你準備收縮的舊檔案組，你反正要收縮（或縮小它的方式下來，如果它的主檔案組）。
基本上你需要提供一些更多的空間，才可以收縮的舊檔案，但它是一個更清晰的設定。
the method i like to recommend is as follows:
create a new filegroup
move all affected tables and indexes into the new filegroup using the create index … with (drop_existing = on) on syntax, to move the tables and remove fragmentation from them at the same time
drop the old filegroup that you were going to shrink anyway (or shrink it way down if its the primary filegroup)
basically you need to provision some more space before you can shrink the old files, but it’s a much cleaner mechanism.
如果你完全沒有選擇需要收縮日志檔案，請注意這個操作會導緻索引的碎片化，你應該在收縮資料檔案采取一些步驟消除它可能導緻的性能問題，唯一的方式是用
dbcc indexdefpage或 alter index
...reorganize消除索引的碎片不要引起資料檔案的增長,這些指令要求擴充空間8kb的頁代替重建一個新的索引在索引重建操作中。
底線 — — 盡量避免不惜一切代價運作資料檔案收縮
------------------------------------------------分割線----------------------------------------
是以，還在用作業定期收縮資料檔案或資料庫開啟了“自動收縮”屬性的朋友們，請及時糾正你們的錯誤認識吧！