隨著“金盾工程”建設的逐步深入和公安信息化的高速發展，公安計算機應用系統被廣泛應用在各警種、各部門。與此同時，應用系統體系的核心、系統數據的存放地――數據庫也隨著實際應用而急劇膨脹，一些大規模的系統，如人口系統的數據甚至超過了1000萬條，可謂海量。那麼，如何實現快速地從這些超大容量的數據庫中提取數據（查詢）、分析、統計以及提取數據後進行數據分頁已成為各地系統管理員和數據庫管理員亟待解決的難題。 在以下的文章中，我將以“辦公自動化”系統為例，探討如何在有著1000萬條數據的MS SQL SERVER數據庫中實現快速的數據提取和數據分頁。以下代碼說明了我們實例中數據庫的“紅頭文件”一表的部分數據結構： CREATE TABLE [dbo].[TGongwen] ( --TGongwen是紅頭文件表名 [Gid] [int] IDENTITY (1, 1) NOT NULL , --本表的id號，也是主鍵 [title] [varchar] (80) COLLATE Chinese_PRC_CI_AS NULL , --紅頭文件的標題 [fariqi] [datetime] NULL , --發布日期 [neibuYonghu] [varchar] (70) COLLATE Chinese_PRC_CI_AS NULL , --發布用戶 [reader] [varchar] (900) COLLATE Chinese_PRC_CI_AS NULL , --需要浏覽的用戶。每個用戶中間用分隔符“,”分開 ) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY] GO 下面，我們來往數據庫中添加1000萬條數據： declare @i int set @i=1 while @i<=250000 begin insert into Tgongwen(fariqi,neibuyonghu,reader,title) values('2004-2-5','通信科','通信科,辦公室,王局長,劉局長,張局長,admin,刑偵支隊,特勤支隊,交巡警支隊,經偵支隊,戶政科,治安支隊,外事科','這是最先的25萬條記錄') set @i=@i+1 end GO declare @i int set @i=1 while @i<=250000 begin insert into Tgongwen(fariqi,neibuyonghu,reader,title) values('2004-9-16','辦公室','辦公室,通信科,王局長,劉局長,張局長,admin,刑偵支隊,特勤支隊,交巡警支隊,經偵支隊,戶政科,外事科','這是中間的25萬條記錄') set @i=@i+1 end GO declare @h int set @h=1 while @h<=100 begin declare @i int set @i=2002 while @i<=2003 begin declare @j int set @j=0 while @j<50 begin declare @k int set @k=0 while @k<50 begin insert into Tgongwen(fariqi,neibuyonghu,reader,title) values(cast(@i as varchar(4))+'-8-15 3:'+cast(@j as varchar(2))+':'+cast(@j as varchar(2)),'通信科','辦公室,通信科,王局長,劉局長,張局長,admin,刑偵支隊,特勤支隊,交巡警支隊,經偵支隊,戶政科,外事科','這是最後的50萬條記錄') set @k=@k+1 end set @j=@j+1 end set @i=@i+1 end set @h=@h+1 end GO declare @i int set @i=1 while @i<=9000000 begin insert into Tgongwen(fariqi,neibuyonghu,reader,title) values('2004-5-5','通信科','通信科,辦公室,王局長,劉局長,張局長,admin,刑偵支隊,特勤支隊,交巡警支隊,經偵支隊,戶政科,治安支隊,外事科','這是最後添加的900萬條記錄') set @i=@i+1000000 end GO 通過以上語句，我們創建了25萬條由通信科於2004年2月5日發布的記錄，25萬條由辦公室於2004年9月6日發布的記錄，2002年和2003年各100個2500條相同日期、不同分秒的由通信科發布的記錄（共50萬條），還有由通信科於2004年5月5日發布的900萬條記錄，合計1000萬條。
一、因情制宜，建立“適當”的索引 建立“適當”的索引是實現查詢優化的首要前提。 索引（index）是除表之外另一重要的、用戶定義的存儲在物理介質上的數據結構。當根據索引碼的值搜索數據時，索引提供了對數據的快速訪問。事實上，沒有索引,數據庫也能根據SELECT語句成功地檢索到結果，但隨著表變得越來越大，使用“適當”的索引的效果就越來越明顯。注意，在這句話中，我們用了“適當”這個詞，這是因為，如果使用索引時不認真考慮其實現過程，索引既可以提高也會破壞數據庫的工作性能。 （一）深入淺出理解索引結構 實際上，您可以把索引理解為一種特殊的目錄。微軟的SQL SERVER提供了兩種索引：聚集索引（clustered index，也稱聚類索引、簇集索引）和非聚集索引（nonclustered index，也稱非聚類索引、非簇集索引）。下面，我們舉例來說明一下聚集索引和非聚集索引的區別： 其實，我們的漢語字典的正文本身就是一個聚集索引。比如，我們要查“安”字，就會很自然地翻開字典的前幾頁，因為“安”的拼音是“an”，而按照拼音排序漢字的字典是以英文字母“a”開頭並以“z”結尾的，那麼“安”字就自然地排在字典的前部。如果您翻完了所有以“a”開頭的部分仍然找不到這個字，那麼就說明您的字典中沒有這個字；同樣的，如果查“張”字，那您也會將您的字典翻到最後部分，因為“張”的拼音是“zhang”。也就是說，字典的正文部分本身就是一個目錄，您不需要再去查其他目錄來找到您需要找的內容。 我們把這種正文內容本身就是一種按照一定規則排列的目錄稱為“聚集索引”。 如果您認識某個字，您可以快速地從自動中查到這個字。但您也可能會遇到您不認識的字，不知道它的發音，這時候，您就不能按照剛才的方法找到您要查的字，而需要去根據“偏旁部首”查到您要找的字，然後根據這個字後的頁碼直接翻到某頁來找到您要找的字。但您結合“部首目錄”和“檢字表”而查到的字的排序並不是真正的正文的排序方法，比如您查“張”字，我們可以看到在查部首之後的檢字表中“張”的頁碼是672頁，檢字表中“張”的上面是“馳”字，但頁碼卻是63頁，“張”的下面是“弩”字，頁面是390頁。很顯然，這些字並不是真正的分別位於“張”字的上下方，現在您看到的連續的“馳、張、弩”三字實際上就是他們在非聚集索引中的排序，是字典正文中的字在非聚集索引中的映射。我們可以通過這種方式來找到您所需要的字，但它需要兩個過程，先找到目錄中的結果，然後再翻到您所需要的頁碼。 我們把這種目錄純粹是目錄，正文純粹是正文的排序方式稱為“非聚集索引”。 通過以上例子，我們可以理解到什麼是“聚集索引”和“非聚集索引”。 進一步引申一下，我們可以很容易的理解：每個表只能有一個聚集索引，因為目錄只能按照一種方法進行排序。 （二）何時使用聚集索引或非聚集索引 下面的表總結了何時使用聚集索引或非聚集索引（很重要）。 動作描述 使用聚集索引 使用非聚集索引 列經常被分組排序 應 應 返回某范圍內的數據 應 不應 一個或極少不同值 不應 不應 小數目的不同值 應 不應 大數目的不同值 不應 應 頻繁更新的列 不應 應 外鍵列 應 應 主鍵列 應 應 頻繁修改索引列 不應 應 事實上，我們可以通過前面聚集索引和非聚集索引的定義的例子來理解上表。如：返回某范圍內的數據一項。比如您的某個表有一個時間列，恰好您把聚合索引建立在了該列，這時您查詢2004年1月1日至2004年10月1日之間的全部數據時，這個速度就將是很快的，因為您的這本字典正文是按日期進行排序的，聚類索引只需要找到要檢索的所有數據中的開頭和結尾數據即可；而不像非聚集索引，必須先查到目錄中查到每一項數據對應的頁碼，然後再根據頁碼查到具體內容。 （三）結合實際，談索引使用的誤區 理論的目的是應用。雖然我們剛才列出了何時應使用聚集索引或非聚集索引，但在實踐中以上規則卻很容易被忽視或不能根據實際情況進行綜合分析。下面我們將根據在實踐中遇到的實際問題來談一下索引使用的誤區，以便於大家掌握索引建立的方法。 1、主鍵就是聚集索引 這種想法筆者認為是極端錯誤的，是對聚集索引的一種浪費。雖然SQL SERVER默認是在主鍵上建立聚集索引的。 通常，我們會在每個表中都建立一個ID列，以區分每條數據，並且這個ID列是自動增大的，步長一般為1。我們的這個辦公自動化的實例中的列Gid就是如此。此時，如果我們將這個列設為主鍵，SQL SERVER會將此列默認為聚集索引。這樣做有好處，就是可以讓您的數據在數據庫中按照ID進行物理排序，但筆者認為這樣做意義不大。 顯而易見，聚集索引的優勢是很明顯的，而每個表中只能有一個聚集索引的規則，這使得聚集索引變得更加珍
