问题标签 [heap-table]

我使用的是SQL Server 2008。我知道如果一个表没有聚集索引，那么它被称为堆，否则存储模型称为聚集索引（B-Tree）。

我想了解更多关于堆存储的确切含义、它的外观以及它是否被组织为“堆”数据结构（例如最小堆、最大堆）的更多信息。有什么推荐的读物吗？我想要更多的内部知识，但不要太深。:-)

提前谢谢，乔治

就 SQL 术语而言，HEAP 是否代表具有非聚集索引的表？

还是有细微差别，或者有完全不同的含义？

我对 MySQL 很陌生。我的问题可能有问题，如果是，请更正或解释。

我刚刚通过在 Google 上搜索定义了解了堆表和临时表。 它们之间的确切区别是什么以及两者的实时用途是什么？

根据我的知识或我读过的内容：

堆表：内存中存在的表称为堆表。在 MySql 中创建 HEAP 表时，用户需要将 TYPE 指定为 HEAP。这些表现在更普遍地称为内存表。这些内存表从来没有像“BLOB”或“TEXT”这样的数据类型的值。他们使用使他们更快的索引。

临时表：临时表在某些情况下对于保存临时数据可能非常有用。临时表是当当前客户端会话终止时它们将被删除。

我有一张大约有 4000 万行的表。这个表是一个堆，有几个非聚集索引。我一直认为 1 行只能有一次前向提取。

我sp_blitzindex从 Brent Ozar 跑来诊断当前的性能问题。

根据 sp_blitzindex，此堆有超过 50 亿次转发提取 (...)。

谁能解释一下这是怎么可能的？我不是在寻找任何设计考虑因素，只是对它如何工作的解释。非常感谢！问候， SQL_M。

我很清楚堆中的转发记录是什么。由于我想将转发记录保持在 0，因此我们决定仅更新无法扩展的列。

最近在我的系统上，我遇到了转发记录。表设计是这样的：

插入语句总是带入所有列，因此没有一个为 NULL。我检查了查询日志。我为 LoadEndTime 插入一个值“9999-12-31”。

现在系统像这样对 LoadTime 执行更新。

由于始终填充 LoadEntTime 列，因此在执行更新时该列不应在行内扩展。它应该是一个适当的更新。在那个过程之后，我仍然总是收到转发记录......这对我来说没有意义......

我有一个启用了 RCSI 的 SQL Server 2016 数据库，它实际上是一堆堆。除了一个表之外，数据库中的每个其他表都是一个堆，最大的堆约为 200GB，占数据库总大小的 50% 以上。

这个特殊的大堆有两个 lob 列，都具有 varbinary(max) 数据类型。堆也有许多非聚集索引，幸好这些非聚集索引中都不存在 varbinary(max) 列，因此它们的大小相对较小。

供应商提供了一个清理脚本，该脚本从应用程序服务器运行并从这个大堆中清除数据。经过一番调查，我发现此清理脚本不会删除整行，而是根据某些条件将 varbinary(max) 列之一设置为 null。

以下是有关堆的一些详细信息：

在这种情况下我的理解是通过将lob列中的值设置为null释放的空间不会被自动回收，这是无论表是堆还是集群的行为，如果我错了，请纠正我.

在这篇 Microsoft文章和这篇文章中，它就索引重组操作说明了以下内容：

REORGANIZE ALL 对所有索引执行 LOB_COMPACTION。对于每个索引，这会压缩聚集索引、基础表或非聚集索引中包含的列中的所有 LOB 列。

指定 ALL 时，将重组与指定表或视图关联的所有索引，并压缩与聚集索引、基础表或包含列的非聚集索引关联的所有 LOB 列。

我发现这些陈述模棱两可而且不是很清楚。谁能确认如果我运行“ALTER INDEX ALL ON REORGANIZE WITH (LOB_CAMPACTION = ON)”语句，即使它们不存在于任何非聚集索引中，它也会 压缩 varbinary(max) LOB 列并且只在底层堆中？这背后的基本原理是回收应用程序作业释放的任何空间，该作业将 LOB 列设置为 null 以用于符合条件的行。

此外，您还可以看到这个堆有许多转发的记录。我还怀疑整行已从堆中删除，但由于已知的对堆的删除行为而未解除分配，其中行仅在通过表锁查询提示显式获取表锁时才解除分配或通过锁升级。考虑到这一点，我正在考虑禁用堆上的所有非聚集索引，重建堆然后重新启用非聚集索引。此操作是否还会重新声明/压缩 lob 列中的任何未使用空间以及删除转发的记录和已删除但未完全取消分配的行？

免责声明 - 此数据库由供应商设计，创建聚集索引是不可接受的。使用这个数据库的应用程序在周末不使用，因此我有很大的维护窗口，所以虽然重建堆可能是资源密集型和痛苦的，但它是可行的。

我刚刚继承了一个“新”SQL Server，并在其上运行了 sp_blitz。

SP_Blitz 警告我正在积极查询的堆。该表中只有 1 行。这是一个设置表，因此不会有更多行到达。

添加聚集索引是否会给我带来任何好处（除了在 sp_blitz 中少一行/唠叨）？

我发现了很多旧文档，比如 2010 年的这个页面，关于 SQL Azure 如何需要聚集索引并且不支持没有它们的表。

然而，10年后还是这样吗？我找不到任何清晰的、更新的文档。

这份 2016 年的文档讨论了“堆（没有聚集索引的表）”，适用于 SQL Server 和 Azure SQL 数据库。因此，我猜想现在支持没有聚集索引的表。是这样吗？我希望看到它更清楚地记录它。

请注意，这不是一个通用的软件推荐请求——它是一个非常真实的“是”或“否”类型的问题。

似乎在 2019 版之前的 SQL Server 中，集群键/键上升到不具有唯一非聚集索引的树结构。使用更大和多个集群键/键，您可以获得更宽更高的树，这会花费您更多的存储大小和内存大小。

因此，我们曾经与PK聚集键分开我的问题是

1. SQL Server 2019 和 Azure 在非聚集索引方面是否发生了变化？
2. 堆根本没有聚类键/键，堆中的索引方式是什么？