主要注意事项
我看到了堆的一个重要优势，而集群表的一个优势，再加上第三个考虑因素，无论哪种方式都可以。
堆为您节省了间接层。索引包含行ID，它们直接指向磁盘位置（不是，实际上，但是尽可能直接）。因此，针对堆的索引查找应该花费大约是针对簇表的非聚簇索引查找的一半。
归因于（几乎）自由索引，对聚集索引本身进行了排序。因为聚簇索引是按照数据的物理顺序反映的，所以它在实际数据本身的顶部占用相对较小的空间，当然无论如何您都必须存储这些空间。因为它是物理排序的，所以针对此索引的范围扫描可以查找到起点，然后非常有效地将其压缩到终点。
堆上的索引引用了64位的RID。如前所述，聚簇表上的非聚簇索引引用聚簇键，聚簇键可以更小（32位INT），相同（64位BIGINT）或更大（48位DATETIME2()加32位INT，或128位GUID）。显然，更广泛的参考意味着更大，更昂贵的索引。
空间要求
使用这两个表：
CREATE TABLE TmpClustered
(
ID1 INT NOT NULL,
ID2 INT NOT NULL
)
ALTER TABLE TmpClustered ADD CONSTRAINT PK_Tmp1 PRIMARY KEY CLUSTERED (ID1)
CREATE UNIQUE INDEX UQ_Tmp1 ON TmpClustered (ID2)
CREATE TABLE TmpNonClustered
(
ID1 INT NOT NULL,
ID2 INT NOT NULL
)
ALTER TABLE TmpNonClustered ADD CONSTRAINT PK_Tmp2 PRIMARY KEY NONCLUSTERED (ID1)
CREATE UNIQUE INDEX UQ_Tmp2 ON TmpNonClustered (ID2)
...每个记录都有870万条记录，两个记录所需的空间均为150 MB；群集表的索引为120 MB，非群集表的索引为310 MB。这反映出聚簇索引比RID窄，并且聚簇索引主要是“免费赠品”。如果没有启用唯一索引ID2，则非集群表所需的索引空间将降至155 MB（如您所料，为一半），而集群PK 的索引空间仅为150 KB-几乎没有。
因此，具有32位索引（名义上总共64位）的群集表中的32位字段的非聚簇索引占用了120 MB，而具有64位的堆中的32位字段的索引却占用了120 MB RID（总共96位，名义上）占用了155 MB，比天真地期望从64位密钥更改为96位密钥所增加的50％少一点，但是当然，开销会减小有效大小的差异。
填充两个表并创建它们的索引对于每个表花费的时间相同。在运行涉及扫描或搜寻的简单测试时，我发现表之间没有实质性的性能差异，这与gbn有用链接的Microsoft白皮书相符。所述论文的确显示出高度并发访问的显着差异。我不确定为什么会发生这种情况，希望比我拥有使用大量OLTP系统的经验更多的人可以告诉我们。
添加〜40字节的随机可变长度数据不会明显改变这种等效性。INT也不用宽UUID 替换s（每个表的速度减慢到大约相同的程度）。您的里程可能会有所不同，但是在大多数情况下，是否有索引比哪种索引更为重要。
点点滴滴
对非聚簇索引进行范围扫描（因为表是堆索引或索引不是聚簇索引），涉及扫描索引，然后针对每个命中对表进行查找。这可能非常昂贵，因此仅扫描表有时会更便宜。但是，您可以使用覆盖索引来解决此问题。无论是否对表进行群集，这都适用。
正如@gbn指出的那样，没有简单的方法来压缩堆。但是，如果您的表随着时间的推移逐渐增加（这是一种很常见的情况），则几乎没有浪费，因为删除所释放的空间将被新数据填充。
我见过的关于堆与集群表的几个讨论提出了一个奇怪的草人论点，即没有索引的堆不如集群表，因为它总是需要进行表扫描。确实是这样，但是更有意义的比较是“大型索引良好的群集表”与“大型索引良好的堆”。如果您的表很小，或者您总是要进行表扫描，那么是否对它进行群集都没关系。
由于聚簇表中的每个索引都引用聚簇索引，因此它们实际上是所有覆盖索引。引用索引列和集群列的查询可以执行索引扫描，而无需任何表查找。如果您的聚簇索引是一个合成键，那么通常这没有什么价值，但是如果您仍然需要检索它是一个业务键，那么这是一个很好的功能。
TL; DR
我是数据仓库专家，而不是OLTP专家。对于事实表，我几乎总是在最可能需要范围扫描的字段（通常是日期字段）上使用聚簇索引。对于维度表，我将其聚集在PK上，因此已针对事实表进行了合并联接的预排序。
使用聚簇索引的原因有很多，但是如果这些原因都不适用，那么开销可能就不值得了。我怀疑人们普遍使用聚簇索引的背后有很多“我们一直都这样做”和“这只是最佳实践”。与尝试既您的数据和您的负载，看看有什么效果最好。