这个问题是本网站关于堆的评分最高的问题。它询问了堆的使用情况。但是，我认为非常大的堆（例如数千 GB）是一种特殊情况，值得单独提出一个问题。
随着聚集索引的大小增加，聚集索引惩罚也会增加，即从非聚集索引中获取剩余键所需的逻辑读取次数。堆的情况并非如此。我认为堆被不公平地忽略了，因为太多人要么从数据仓库中学习了所有的数据库设计（主键扫描，因此聚集索引，通常是一个好主意），要么从未在足够大的数据库上工作过，无法感受到拥有真正大表的代价。
这就产生了一个问题：索引良好的非常大的堆是否具有在索引良好的非常大的聚类表中找不到的实际用例？
为避免这个问题太过宽泛，我们采用以下约束。假设：
- 1 TB 堆
- 标准版盒子
- OLTP 环境（不是数据仓库）。
总的来说，这意味着您的缓冲池 RAM 限制为 128 GB，并且不会定期对主键进行大规模扫描。从磁盘读取整个堆会很麻烦，因此有关将表用作暂存表或仅备份表的任何答案都不适用。
当然。聚集表有很多优点，但它们并不总是最佳解决方案。但请注意，某些 SQL Server 功能需要聚集索引或主键。
聚集 B 树索引主要体现在其叶级页面的逻辑顺序中，确实“免费”提供了一些好处，但也有缺点：
您只能有一个这样的索引，因为它是主要存储对象。
B 树的上层可以表示开销，如问题链接文章中提到的那样。
额外的 I/O 效应是真实存在的，尽管经常被夸大。上层确实有保留在缓存中的趋势，但这并不能保证。无论如何，每次查找时都必须锁定和导航额外的页面。
聚簇索引包括叶子上的所有行内列和行外指针。这使得叶子索引键之间的空间最大。换句话说，聚簇索引通常是最不密集的索引。
以堆形式组织的同一张表需要非聚集索引来提供类似的访问方法。非聚集索引的上层与聚集索引非常相似，但一般来说，叶级页面会更加密集。
大多数非常大的 OLTP 表都需要多个索引来支持大量查询。这些非聚集索引通常比较窄，优先使用具有少量书签查找的高选择性索引搜索，而不是更宽的覆盖索引。在这种情况下，完全覆盖索引通常不切实际。
这些访问路径中的每一条都受益于 RID 行定位器提供的更高叶密度和/或直接访问，而不是通过聚类键和相关的 b 树进行间接访问。
曾经有一段时间，单列
integer聚簇键非常常见，使得 8 字节 RID 的大小增加一倍。现在这种情况已经很少见了，因为即使是所谓的“代理”通常也是如此bigint。许多聚簇索引属于更宽的类型、基于字符串或多列。现在，RID 的大小往往是一种优势。用堆和单个非聚集索引替换非常大的聚集表通常不会产生任何好处。如果有的话，其优势来自于支持工作负载所需的最佳非聚集索引数量的增加以及可接受的性能。每种非聚集访问方法都受益于更高效的查找路径。
在问题中描述的有限场景中，如果存在许多高度选择性的 OLTP 查询，则值得研究堆安排，这些查询最好由中等到大量高度优化、狭窄的非聚集索引、选择性 RID 查找以及仅索引范围扫描来满足。
您能看到多少好处取决于硬件的性能特征，以及优化器选择的执行计划的细节（尤其是预取）。堆的所有常见注意事项仍然适用。请注意空间管理问题以及扩大更新如何导致转发记录。
根据工作负载中的其他表，具有二级索引的大型堆可能有利于内置的星型连接优化。这些计划通常具有基表查找（提取）。
请记住，堆表也可以被分区，这有时很有用。
尽管如此，这些都不是新鲜事。性能方面的这个方面很少会胜过所有其他考虑因素。尽管如此，这是一个值得考虑的真正因素。大多数人最终都会对集群方案感到非常满意，即使使用堆基在技术上可以实现略微更好的性能。