sqlserver表碎片是怎么产生的

sqlserver表碎片是如何产生的
如题 

我这么理解

比方说 有一张表 有十条数据 表的数据是递增的 我删除了第五条

那么如果用户新增一条数据的话 应该是插入第十条后面 

那么第五条的空间可能不会在被利用了 】

这样我理解为表碎片了 

请各位大牛 解答一下 感激之至！
------解决方案--------------------
这个是逻辑碎片，
碎片有区碎片和逻辑碎片，
区碎片，当需要1个数据页分成2页的时候产生
逻辑碎片就是你说的那样
------解决方案--------------------
    这么理解也还真是独特， 当表有聚集索引的时候这些会被删除的记录应该会标记为虚影，虚影记录大概60秒被一个叫什么clear的线程清除掉。这样当有用户需要这空间时就直接被利用了。这个叫索引碎片，因为聚集索引就是数据本身吗？产生碎片的主要原因就是页不完成的删除也就是一页数据100条数据只删除了60条。和分页。
    你说的这个是堆结构的表，也就是没有聚集索引的表，如果在堆上删除时获取行级或分页级锁，这些空间不被释放，那怕你删除某一页的最后一条数据。这部分空间也不会马上释放。算了我懒得打字了，直接上某论坛上的例子吧。

今天给大家分享一个”删除大量数据后SQL Server性能下降”的案例。一般而言，数据库数据减少后，应该有助于提高SQL server的整体性能。可是在这个案例中，情况恰恰相反。


 


症状


=========


-          删除大量数据后SQL Server性能下降


-          一些存储过程之前运行20分钟左右，现在需要运行2-3个小时。


 


背景信息


=========


-          大量数据通过DELETE语句而删除


-          数据删除后，客户进行了相关的维护工作 : 重建索引和更新统计数据


-          性能变慢的存储过程会对一些表做很多的”DELETE”，”INSERT”和”SELECT”操作。


 


调查


=========


-          相关的表都是堆( heap table)


 


-          这些表中并没有大量数据


 


-          DBCC CHECKCONTIG 结果显示表很大，但其页的密度 (Page Density) 却相当小。


 


DBCC SHOWCONTIG scanning 'tblA' table...


Table: 'tblA' (322816212); index ID: 0, database ID: 14


TABLE level scan performed.


- Pages Scanned................................: 1779939 à13.6GB


- Extents Scanned..............................: 223475


- Extent Switches..............................: 223474


- Avg. Pages per Extent........................: 8.0


- Scan Density [Best Count:Actual Count].......: 99.56% [222493:223475]


- Extent Scan Fragmentation ...................: 23.65%


- Avg. Bytes Free per Page.....................: 8059.1


- Avg. Page Density (full).....................: 0.43%


 


DBCC SHOWCONTIG scanning 'tblB' table...


Table: 'tblB' (1005246636); index ID: 0, database ID: 14


TABLE level scan performed.


- Pages Scanned................................: 215600 à1.6GB


- Extents Scanned..............................: 27269


- Extent Switches..............................: 27268