关于通过聚集索引以及堆来对比数据表组织结构-SQLServer最优实践 的一点看法

本文主要测试聚集索引表和堆表的插入、删除、更新、查询以及并发情况下的查询效率

在单用户插入、删除、更新、查询的情况下，聚集索引表的效率要优于堆表

这是因为在插入、删除、更新操作时，聚集索引表的读写操作只有一次，而堆表的读写操作则分别为两次，即需要维护索引数据和表数据。

再插入时Page splits/sec的指标，聚集索引表远远高于堆表，这是在插入数据时，由于数据是按照聚集索引列进行组织的，所以聚集索引表的叶子/非叶子节点的分裂远远高于堆表。

聚集索引表情况下Page splits/sec=Pages Allocated/sec，即分裂的速度也即重新分配的速度

而堆表情况下Pages Allocated/sec要大于聚集索引表，这是因为堆表页面的无序性造成的，必须每次从IAM页中进行分配，而聚集索引表则可以通过双向链表来查找。

Pages Allocated/sec为SQL Server 实例的所有数据库中每秒分配的页数。这些页包括从混合区和统一区中分配的页。

对于查询而言，聚集索引当然是最快的选择了，堆表则需要进行两次查找。更新和删除操作的情况与其类似。

在并发情况下，数据的插入效率，堆表则好于聚集索引表，主要体现在Page splits/sec和page latch waits per second这两个指标上，page latch waits per second可以理解为对页面的争用等待数，因为聚集索引的数据组织的排序性，比如要对热点页面发生相应的争用，而堆表则不存在该问题。

综上，一般情况下，聚集索引表的性能要优于堆表。

但该测试也存在一定的问题，测试数据的有序性无法论证，索引列数据的有序性对插入以及空间利用率都有很大的关系，同时也会影响后续的更新、删除操作的测试。

其次是表的列宽太小，并且初始索引填充因子皆为0，对于更新、删除操作的测试也没有太大意义，因为更新的列宽没有发生变化，对页面的分裂和空间利用率不产生任何影响