压缩，碎片整理，回收空间，收缩数据库与收缩文件

Question

[1]指出：

• “从堆中删除数据时，页面上的数据不会被压缩（回收）。并且如果堆页面的所有行都被删除，则通常无法回收整个页面”

• “ ALTER INDEX重建和重组选项不能用于对堆中的空间进行碎片整理（但它们可以用于对堆中的非聚集索引
  进行碎片整理。）如果要在SQL Server 2005中对堆进行碎片整理，则需要三个选项：
  

  • 1）在堆上创建一个聚集索引，然后删除该聚集索引；
  • 2）使用SELECT INTO将旧表复制到新表；或者
  • 3）使用BCP或SSIS将数据从旧表移动到新表。
    在SQL Server 2008中，更改了ALTER TABLE命令，因此它现在具有重建堆的能力”
    

请解释一下：
MS SQL Server 2005中的压缩，（碎片）整理，回收空间，收缩文件和收缩数据库之间有什么区别？
收缩文件和收缩数据库在MS SQL Server 2005中完成什么工作？

更新：
该问题是受[2]中的讨论启发的-如何在MS SQL Server 2005中缩小数据库？

Update2： @PerformanceDBA，
抱歉！您在短短一周内就获得了500多种收益。这太了不起了！

您的图表
再次感谢您的宝贵时间。
我待会儿再问，不在这里。
内在不是我最主要的事情，也不是最简单的事情。

它非常简洁，一般来说，颂歌不会引起任何疑问或疑问。

我希望使用一些工具，描述/说明，技术来提出自己的疑问，问题和讨论。
例如，Plz会看到我的问题：

• http://www.sqlservercentral.com/Forums/Topic1013693-373-2.aspx#bm1014385
• http://www.sqlservercentral.com/Forums/Topic1013975-373-1.aspx

它们基本上是我所要求的内容的重复内容，但不能在stackoverflow.com中进行讨论

Update3： @PerformanceDBA，
再次感谢我，我的问题的主要目的是确定解决具体问题的方法（基于和避免什么），这些文档，文章，讨论，答案等相互矛盾，这些对您有所帮助检测。

目前，我在这方面没有其他问题（无法解决并阻止我）。

[1]
Brad McGehee。Brad的《确定索引指南》（2009年6月11日）
http://www.simple-talk.com/sql/database-administration/brads-sure-guide-to-
indexes/
[2]
对“收缩数据库”问题的回答和反馈低于其初始大小”
https://stackoverflow.com/questions/3543884/shrink-a-database-below-its-
initial-
size/3774639#3774639

Answer 1

一个多月没有人碰过这个。

前三个答案的答案实际上在“
我为您制作
的
图表”中
，您无需费心去消化和询问有关…的问题，它通常用作讨论的平台。

（这是我精心制作的 Sybase 图表的精简版，为MS上下文提供了该图表，如果您需要完整的Sybase集，则在该文档的底部有一个链接。）

因此，我也不会花很多时间在你身上。而且，请不要索取“参考站点”的链接，没有这样的东西（可用的是非技术垃圾），这正是我拥有自己的图表的原因。很少有人了解MS
SQL Internals。

回收空间

那是正确的术语。MS不会从页面中删除已删除的行，也不会从扩展区中删除已删除的页面。回收空间是一项通过堆操作并删除未使用的（a）行和（b）页面的操作。当然，这会更改RowId，因此必须重新构建所有非聚集索引。

压缩

在粘贴的文本中：与回收空间相同。

碎片整理

全面清除未使用空间的操作。共有三个级别：

一，数据库（AllocationUnits），跨所有对象

二。对象（范围和页面），页面链，拆分页面，溢出页面

三，仅堆（无聚簇索引），该帖子的主题

收缩文件

完全不同的操作，以减少在设备（文件）上分配的空间。这将删除未使用的AllocationUnits（因此“缩小”），但是对碎片整理的AllocationUnits有所不同。

收缩数据库

对数据库执行相同的操作；数据库在所有设备上使用的所有设备分配。

对评论的回应

SSC的发布者毫无头绪，不会直接解决您的问题。

• 没有集群表之类的东西（CREATE CLUSTERED TABLE失败）
• 有一个聚集索引之类的东西（CREATE CLUSTERED INDEX成功）
• 根据我的图表，它是一个单一的物理结构；聚集索引包含行，因此消除了堆
• 没有聚集索引的地方，有两个物理结构：堆和单独的非聚集索引

现在，在您使用DBCC入门之前，DBCC的级别太低，无知的人们无法识别，更不用说解释其原因和理由了，您需要了解并确认上述内容：

• 创建一个Table_CI（我们打算添加一个CI，仍然没有诸如簇表之类的东西）
• 向其添加唯一的聚集索引UC_PK

• 添加几行

• 创建表堆

• 向其添加唯一的非聚集索引NC_PK

• 添加几行

• SELECT * FROM sysindexes，其中id = OBJECT_ID（“ Table_CI”）

• SELECT * FROM sysindexes WHERE id = OBJECT_ID（“ Heap”）

• 请注意，每个sysindexes条目都是完整的，独立的数据存储结构（请参阅各列）

• 考虑输出

• 与我的图比较
• 与宇宙中的垃圾相比

将来，我将不再回答有关宇宙中混乱的垃圾以及其他网站上的错误和误报的问题（我不在乎他们是否是MS认证专家，他们证明他们无力检查自己的数据库并确定正确的信息）

我费心创建准确的图表是有原因的（MS的手册，图片和所有可用信息都是垃圾；您从：authority”查找准确的信息无用，因为“
authority”从技术上讲破产）。

甚至Gail最终都发现， 我怀疑您会在对底层内部结构有所了解之前，从更多的索引总体架构中受益。

除了，没有任何东西。这不会造成混淆，非技术性和不一致。

我费心创建准确的图表是有原因的。

返回到DBCC。盖尔是完全不正确的。在聚集索引（包括行）中，单个页面包含行。是的，行。那就是索引的叶子级别。有一个B树，它位于页面顶部，但是它很小，您看不到它。查看sysindexes输出。根和首页指针指向页面；这是聚簇索引的根。当您潜入海洋时，您需要知道要寻找的东西以及在哪里可以找到它，否则您将找不到想要的东西，并且您会因自己偶然发现的漂浮物和喷射物质而分心。

现在看一下NCI和堆的两个单独的结构。

哦，MS已经从使用OAM术语更改为以数据结构为索引的IAM。这带来了混乱。就数据结构（sysindexes中的条目）而言，它们都是对象。它们可能是也可能不是索引）。关键是，谁在乎，我们知道它是什么，它是一个ObjectAllocationMap……如果您在NCI上看，gee，它是一个IndexObjectAllocationMap；如果您正在查看堆，则为HeapObjectAllocMap。我将考虑在CI情况下的情况。在追踪或使用它时（找到属于该对象的页面并不重要，它们都是对象。这样做时，您需要知道，某些对象具有PageChain，而其他对象则没有PageChain（另一个您的问题）。配置项有它们；
NCI和堆没有。

盖尔·肖（Gail Shaw）：“我怀疑这些内部结构是否在任何地方都有记录。毕竟，我们使用的是未记录的功能。索引的定义取决于您询问的对象和外观。

ROTFLMAO。我的侧面受伤了，我看不清其后的帖子。这些应该是聪明的人吗？在IT世界中工作？定义CHANGE？一天中的温度或时间如何？那就是SQL
Server Central？不是偏僻地区吗？

当MS从Sybase窃取SQL
Server时，该文档非常可靠。当然，在每个主要发行版中，他们都“重写”了该文档，文档变得越来越虚弱和蓬松（回想一下我们在另一篇文章中的讨论）。现在，我们拥有可爱的图片，从技术上来说，这些图片会让人们感觉很好，但不准确。这就是为什么像你这样认真的人有问题的原因。图片甚至与手册中的文字不符。

无论如何，定义不会改变。那就是定义的定义。它们在任何情况下都是正确的。嗯，您正在使用的um功能是已记录的普通功能。自1987年以来一直如此。除非MS在某个地方丢失了它，而且没人能找到它。您必须问一个过去的Sybase
Guru，谁记得他们获取的代码中确切的数据结构。而且，如果您真的很幸运，他将了解MoronSociety在2000年，2005年和2008年引入的差异。他甚至可能只有一个准确的图表，可以与您的机器上的sysindexes和DBCC的输出相匹配。如果找到他，请亲吻他的戒指，并给他淋浴。锁上你的女儿们。

（不严重，我的身边正在杀死我，欢乐满溢）。

现在，您知道 我 为什么 不回答有关宇宙中混乱垃圾的问题 吗？在MoronSociety中，有很多白痴。

-----

再次盖尔：

“扫描：
。索引扫描是所有索引的叶级页的完整读取当一个索引扫描聚集索引完成的， 它鈥檚表扫描，但在所有的名字 。
当一个索引扫描被完成查询处理器，无论是否返回所有行，它始终是对索引中所有叶页的完整读取。它绝不是部分扫描。
扫描不仅涉及读取索引的叶级别，较高级别的页面也将作为索引扫描的一部分读取。”

她以快风而得名是一定有原因的。她写“书”吗？是的，幻想小说。热气球是为气球爱好者提供的，而不是IT专业人员。

完整和完整的文件。索引扫描的全部要点以及为什么它应该优先于表扫描，因为它试图避免表扫描，所以：-引擎（执行查询树）可以直接进入索引（​​聚集或非聚集），此时）-导航B树以查找开始的位置（到这一点为止，它与获得几行（即不扫描）非常相同）-B树（从任何优点技术图）是几页，每页包含许多索引条目，因此它非常快-
这是根级加上非叶级-直到找到符合条件的叶级条目-从那时开始，它确实依次通过所述索引的LEAF级别进行扫描（胖蓝色箭头）

• 现在对于NCI，如果您还记得自己的作业，则意味着叶子级页面上充满了index_leaf_level_entry + CI_key
• 因此它是在NCI叶级别上顺序扫描的（这就是为什么仅在NCI的叶级别上存在PageChain的原因，以便它可以浏览）

• 但是在HEAP上到处跳转以获取数据行

• 但是对于CI，叶级是数据行（数据页，只有数据行，这就是为什么您看不到其中的“索引”的原因；非叶级CI页是仅包含index_entries的纯索引页）

• 因此，当它使用PageChain顺序对索引leaf_level进行扫描时，即按顺序扫描数据，它们是相同的操作（绿色绿色箭头）

• 没有堆
• 不能跳来跳去

为了进行比较，然后使用表扫描（仅用于MS）：-堆上没有PageChain-别无选择，只能从头开始-读取每个数据页-
其中许多数据将被碎片化（包含未使用的剩余空间）删除或转发的行）-其他行将完全为空

整个意图是，优化器已经决定不要进行表（堆）扫描，而是可以进行索引扫描（因为它需要的数据比整个数据范围少，并且可以找到数据的起点）。通过某个索引获取该数据）。如果您查看SHOWPLAN，即使是检索一个唯一的PK行，它也会显示“
INDEX
SCAN”。这意味着，它将首先导航B-树，以找到至少一行。然后，它可以扫描叶级别，直到找到终点为止。如果它是一个涵盖的查询，则它永远不会转到数据行。

不能代替聚集索引。