關於通過叢集索引以及堆來對比資料表組織圖-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，對於更新、刪除操作的測試也沒有太大意義，因為更新的列寬沒有發生變化，對頁面的分裂和空間利用率不產生任何影響