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

本文轉自baoqiangwang51CTO部落格，原文連結：http://blog.51cto.com/baoqiangwang/423344，如需轉載請自行聯系原作者