收缩数据文件会导致严重的索引碎片.
生产环境中有个job是定期收缩数据库，最近发现性能急剧下降，检查发现是多数Index存有严重的碎片,但每周都有一个Rebuild Index的job,理论上不该出现严重的碎片问题。最后才发现时dbcc shrinkdatabase的原因。以下是问题重现步骤：
CREATE DATABASE DB_Shrink_Demo
GO
USE DB_Shrink_Demo
GO
CREATE TABLE tb1 (id int identity(1,1) primary key,c1 char(6000))
GO
CREATE TABLE tb2 (id int identity(1,1) primary key,c1 char(6000))
GO
INSERT INTO tb1(c1)
VALUES('abc')
GO 1000
INSERT INTO tb2(c1)
VALUES('abc')
GO 1000
SELECT * FROM sys.dm_db_index_physical_stats(db_id('DB_Shrink_Demo'),object_id('tb2'),1,DEFAULT,'DETAILED')结果如下：此时avg_fragmentation_in_percent值为0.9.
再看页面分配情况：可以见到tb1,tb2几乎没有任何碎片,页面分配很整齐.干掉tb1,腾出可用空间.
TRUNCATE TABLE tb1
GO
DBCC SHRINKDATABASE (DB_Shrink_Demo)
GO
SELECT * FROM sys.dm_db_index_physical_stats(db_id('DB_Shrink_Demo'),object_id('tb2'),1,DEFAULT,'DETAILED')
结果如下：
此时avg_fragmentation_in_percent值已经变成为98.1!!!再看页面分配情况：表面看上去没什么问题，页面分配也很完整，但是依顺序打开页面查看具体资料时却出现了重大问题，索引顺序完全反了！！！
176页(id =1000)：
177页（id=999):
结论：DBCC ShrinkDatabase收缩数据文件时，会依据GAM页面资讯尽量将尾部的数据页面往前面的空余页面挪动，由于Index页面之间是有 Double-link双向链接的，这样就会破坏页面物理跟索引逻辑的关系，导致了索引碎片的产生。
http://blog.csdn.net/Garnett_KG/archive/2010/05/22/5615865.aspx
生产环境中有个job是定期收缩数据库，最近发现性能急剧下降，检查发现是多数Index存有严重的碎片,但每周都有一个Rebuild Index的job,理论上不该出现严重的碎片问题。最后才发现时dbcc shrinkdatabase的原因。以下是问题重现步骤：
CREATE DATABASE DB_Shrink_Demo
GO
USE DB_Shrink_Demo
GO
CREATE TABLE tb1 (id int identity(1,1) primary key,c1 char(6000))
GO
CREATE TABLE tb2 (id int identity(1,1) primary key,c1 char(6000))
GO
INSERT INTO tb1(c1)
VALUES('abc')
GO 1000
INSERT INTO tb2(c1)
VALUES('abc')
GO 1000
SELECT * FROM sys.dm_db_index_physical_stats(db_id('DB_Shrink_Demo'),object_id('tb2'),1,DEFAULT,'DETAILED')结果如下：此时avg_fragmentation_in_percent值为0.9.
再看页面分配情况：可以见到tb1,tb2几乎没有任何碎片,页面分配很整齐.干掉tb1,腾出可用空间.
TRUNCATE TABLE tb1
GO
DBCC SHRINKDATABASE (DB_Shrink_Demo)
GO
SELECT * FROM sys.dm_db_index_physical_stats(db_id('DB_Shrink_Demo'),object_id('tb2'),1,DEFAULT,'DETAILED')
结果如下：
此时avg_fragmentation_in_percent值已经变成为98.1!!!再看页面分配情况：表面看上去没什么问题，页面分配也很完整，但是依顺序打开页面查看具体资料时却出现了重大问题，索引顺序完全反了！！！
176页(id =1000)：
177页（id=999):
结论：DBCC ShrinkDatabase收缩数据文件时，会依据GAM页面资讯尽量将尾部的数据页面往前面的空余页面挪动，由于Index页面之间是有 Double-link双向链接的，这样就会破坏页面物理跟索引逻辑的关系，导致了索引碎片的产生。
http://blog.csdn.net/Garnett_KG/archive/2010/05/22/5615865.aspx
Internals Viewer
公司是专业为国内外出版社、印刷企业与文章小说网站提供打字录入排版校对的专业外包公司，主要提供的业务有打字、排版、校对、信息维护。公司接受2000多家客户的文字外包业务，现向全国公开急聘网络兼职输入员1000名。要求会打字，工作认真仔细，不限学历和年龄。由于前期工作任务有一定难度，工资也相应较高，工资130元/万字，工资通过支付宝、银行转帐、办事处专员送达方式日结。
职位名称：网络兼职打字员
职位要求：会电脑打字，懂WORD软件，上网比较熟练。地区、年龄不限。
职位性质：公司将小说手稿扫描后，EMAIL至员工邮箱或专人送达，员工完成WORD输入后发至公司 邮箱即可,适合在校学生。
工作地点：家里、网吧均可工作。（能上网即可）
职位待遇：130元/万字，工资每日结算。
职位介绍：网络兼职打字员主要工作是负责打字、资料入录，发布信息等，工作简单，但要求细心，有责任心，为人诚实。
网络兼职打字员
申请加入请登录：www.job-sohu.com
因为收缩DB，数据页进行了移动，但索引页又不更新，索引页与数据页对应失效，产生了碎片 页存储本来就可以没有物理顺序，截图显示数据顺序反了，并不能反映就是碎片的原因