SQL Server聚集索引的重要性與選擇聚集索引的條件
文章主要描述的是SQL Server聚集索引的重要性與在選擇聚集索引的條件，前一篇文章我們主要是討論了關于實現小數據量與其海量數據的通用分頁顯示存儲過程。這是因為在將本存儲過程應用于“辦公自動化”系統的實踐中時。
筆者發現這第三種存儲過程在小數據量的情況下，有如下現象：
1、分頁速度一般維持在1秒和3秒之間。
2、在查詢***一頁時，速度一般為5秒至8秒，哪怕分頁總數只有3頁或30萬頁。
雖然在超大容量情況下，這個分頁的實現過程是很快的，但在分前幾頁時，這個1－3秒的速度比起***種甚至沒有經過優化的分頁方法速度還要慢，借用戶的話說就是“還沒有ACCESS數據庫速度快”，這個認識足以導致用戶放棄使用您開發的系統。
筆者就此分析了一下，原來產生這種現象的癥結是如此的簡單，但又如此的重要：排序的字段不是SQL Server聚集索引！
本篇文章的題目是：“查詢優化及分頁算法方案”。筆者只所以把“查詢優化”和“分頁算法”這兩個聯系不是很大的論題放在一起，就是因為二者都需要一個非常重要的東西SQL Server聚集索引。
在前面的討論中我們已經提到了，SQL Server聚集索引有兩個***的優勢：
1、以最快的速度縮小查詢范圍。
2、以最快的速度進行字段排序。
第1條多用在查詢優化時，而第2條多用在進行分頁時的數據排序。
而聚集索引在每個表內又只能建立一個，這使得聚集索引顯得更加的重要。SQL Server聚集索引的挑選可以說是實現“查詢優化”和“高效分頁”的最關鍵因素。
但要既使聚集索引列既符合查詢列的需要，又符合排序列的需要，這通常是一個矛盾。筆者前面“索引”的討論中，將fariqi，即用戶發文日期作為了聚集索引的起始列，日期的精確度為“日”。這種作法的優點，前面已經提到了，在進行劃時間段的快速查詢中，比用ID主鍵列有很大的優勢。
但在分頁時，由于這個聚集索引列存在著重復記錄，所以無法使用max或min來最為分頁的參照物，進而無法實現更為高效的排序。而如果將ID主鍵列作為聚集索引，那么聚集索引除了用以排序之外，沒有任何用處，實際上是浪費了聚集索引這個寶貴的資源。
為解決這個矛盾，筆者后來又添加了一個日期列，其默認值為getdate()。用戶在寫入記錄時，這個列自動寫入當時的時間，時間精確到毫秒。即使這樣，為了避免可能性很小的重合，還要在此列上創建UNIQUE約束。將此日期列作為SQL Server聚集索引列。
有了這個時間型聚集索引列之后，用戶就既可以用這個列查找用戶在插入數據時的某個時間段的查詢，又可以作為唯一列來實現max或min，成為分頁算法的參照物。
【編輯推薦】
