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

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/6517/viewspace-678089/，如需轉載，請註明出處，否則將追究法律責任。