????假設不能設計一個合理的數據庫模型。不僅會添加client和server段程序的編程和維護的難度，並且將會影響系統實際運行的性能。所以，在一個系統開始實施之前，完備的數據庫模型的設計是必須的。

????在一個系統分析、設計階段。由於數據量較小。負荷較低。我們往往僅僅註意到功能的實現。而非常難註意到性能的薄弱之處，等到系統投入實際運行一段時間後，才發現系統的性能在降低。這時再來考慮提高系統性能則要花費很多其它的人力物力，而整個系統也不可避免的形成了一個打補丁project。

????所以在考慮整個系統的流程的時候，我們必須要考慮，在高並發大數據量的訪問情況下，我們的系統會不會出現極端的情況。

（比如：對外統計系統在7月16日出現的數據異常的情況，並發大數據量的的訪問造成。數據庫的響應時間不能跟上數據刷新的速度造成。

詳細情況是：在日期臨界時（00：00：00）。推斷數據庫中是否有當前日期的記錄，沒有則插入一條當前日期的記錄。在低並發訪問的情況下，不會發生故障，可是當日期臨界時的訪問量相當大的時候，在做這一推斷的時候，會出現多次條件成立，則數據庫裏會被插入多條當前日期的記錄，從而造成數據錯誤。

），數據庫的模型確定下來之後，我們有必要做一個系統內數據流向圖，分析可能出現的瓶頸。

????為了保證數據庫的一致性和完整性，在邏輯設計的時候往往會設計過多的表間關聯，盡可能的降低數據的冗余。（比如用戶表的地區。我們能夠把地區另外存放到一個地區表中）假設數據冗余低。數據的完整性easy得到保證，提高了數據吞吐速度，保證了數據的完整性，清楚地表達數據元素之間的關系。

而對於多表之間的關聯查詢（尤其是大數據表）時，其性能將會降低。同一時候也提高了client程序的編程難度。因此，物理設計需折衷考慮，依據業務規則，確定對關聯表的數據量大小、數據項的訪問頻度，對此類數據表頻繁的關聯查詢應適當提高數據冗余設計但添加了表間連接查詢的操作，也使得程序的變得復雜，為了提高系統的響應時間。合理的數據冗余也是必要的。設計人員在設計階段應依據系統操作的類型、頻度加以均衡考慮。

???另外，最好不要用自增屬性字段作為主鍵與子表關聯。不便於系統的遷移和數據恢復。對外統計系統映射關系丟失（******************）。

????原來的表格必須能夠通過由它分離出去的表格又一次構建。使用這個規定的優點是。你能夠確保不會在分離的表格中引入多余的列。全部你創建的表格結構都與它們的實際須要一樣大。應用這條規定是一個好習慣。只是除非你要處理一個非常大型的數據。否則你將不須要用到它。（比如一個通行證系統，我能夠將USERID，USERNAME，USERPASSWORD，單獨出來作個表，再把USERID作為其它表的外鍵）

表的設計詳細註意的問題：

????1、數據行的長度不要超過8020字節。假設超過這個長度的話在物理頁中這條數據會占用兩行從而造成存儲碎片，降低查詢效率。
????2、能夠用數字類型的字段盡量選擇數字類型而不用字符串類型的（電話號碼）。這會降低查詢和連接的性能。並會添加存儲開銷。這是由於引擎在處理查詢和連接回逐個比較字符串中每一個字符。而對於數字型而言僅僅須要比較一次就夠了。

????3、對於不可變字符類型char和可變字符類型varchar 都是8000字節,char查詢快。可是耗存儲空間，varchar查詢相對慢一些可是節省存儲空間。在設計字段的時候能夠靈活選擇，比如username、password等長度變化不大的字段能夠選擇CHAR。對於評論等長度變化大的字段能夠選擇VARCHAR。

????4、字段的長度在最大限度的滿足可能的須要的前提下，應該盡可能的設得短一些。這樣能夠提高查詢的效率，並且在建立索引的時候也能夠降低資源的消耗。

二、查詢的優化?
保證在實現功能的基礎上。盡量降低對數據庫的訪問次數；通過搜索參數，盡量降低對表的訪問行數,最小化結果集，從而減輕網絡負擔；能夠分開的操作盡量分開處理，提高每次的響應速度。在數據窗體使用SQL時。盡量把使用的索引放在選擇的首列。算法的結構盡量簡單；在查詢時。不要過多地使用通配符如SELECT * FROM T1語句，要用到幾列就選擇幾列如：SELECT COL1,COL2 FROM T1；在可能的情況下盡量限制盡量結果集行數如：SELECT TOP 300 COL1,COL2,COL3 FROM T1,由於某些情況下用戶是不須要那麽多的數據的。???
在沒有建索引的情況下，數據庫查找某一條數據。就必須進行全表掃描了。對全部數據進行一次遍歷，查找出符合條件的記錄。在數據量比較小的情況下，或許看不出明顯的區別。可是當數據量大的情況下，這樣的情況就是極為糟糕的了。
SQL語句在SQL SERVER中是怎樣運行的，他們操心自己所寫的SQL語句會被SQL SERVER誤解。

比方：?
select * from table1 where name=‘zhangsan‘ and tID > 10000?
和運行:?
select * from table1 where tID > 10000 and name=‘zhangsan‘?
一些人不知道以上兩條語句的運行效率是否一樣，由於假設簡單的從語句先後上看。這兩個語句的確是不一樣。假設tID是一個聚合索引，那麽後一句僅僅從表的10000條以後的記錄中查找就可以了。而前一句則要先從全表中查找看有幾個name=‘zhangsan‘的，而後再依據限制條件條件tID>10000來提出查詢結果。

?
其實，這樣的操心是不必要的。

SQL SERVER中有一個“查詢分析優化器”。它能夠計算出where子句中的搜索條件並確定哪個索引能縮小表掃描的搜索空間。也就是說，它能實現自己主動優化。盡管查詢優化器能夠依據where子句自己主動的進行查詢優化，但有時查詢優化器就會不依照您的本意進行高速查詢。?
在查詢分析階段。查詢優化器查看查詢的每一個階段並決定限制須要掃描的數據量是否實用。假設一個階段能夠被用作一個掃描參數（SARG）。那麽就稱之為可優化的，並且能夠利用索引高速獲得所需數據。

?
SARG的定義：用於限制搜索的一個操作，由於它一般是指一個特定的匹配，一個值的範圍內的匹配或者兩個以上條件的AND連接。形式例如以下：?
列名 操作符 <常數 或 變量> 或 <常數 或 變量> 操作符 列名?
列名能夠出如今操作符的一邊，而常數或變量出如今操作符的還有一邊。如：?
Name=’張三’?
價格>5000?
5000<價格?
Name=’張三’ and 價格>5000?
假設一個表達式不能滿足SARG的形式。那它就無法限制搜索的範圍了，也就是SQL SERVER必須對每一行都推斷它是否滿足WHERE子句中的全部條件。

所以一個索引對於不滿足SARG形式的表達式來說是沒用的。

?
????所以。優化查詢最重要的就是。盡量使語句符合查詢優化器的規則避免全表掃描而使用索引查詢。

詳細要註意的：

1.應盡量避免在 where 子句中對字段進行 null 值推斷，否則將導致引擎放棄使用索引而進行全表掃描，如：
select id from t where num is null
能夠在num上設置默認值0。確保表中num列沒有null值，然後這樣查詢：
select id from t where num=0

2.應盡量避免在 where 子句中使用!=或<>操作符，否則將引擎放棄使用索引而進行全表掃描。優化器將無法通過索引來確定將要命中的行數,因此須要搜索該表的全部行。

3.應盡量避免在 where 子句中使用 or 來連接條件。否則將導致引擎放棄使用索引而進行全表掃描，如：
select id from t where num=10 or num=20
能夠這樣查詢：
select id from t where num=10
union all
select id from t where num=20

4.in 和 not in 也要慎用，由於IN會使系統無法使用索引,而僅僅能直接搜索表中的數據。如：
select id from t where num in(1,2,3)
對於連續的數值。能用 between 就不要用 in 了：
select id from t where num between 1 and 3

5.盡量避免在索引過的字符數據中，使用非打頭字母搜索。這也使得引擎無法利用索引。?
見例如以下樣例：?
SELECT * FROM T1 WHERE NAME LIKE ‘%L%’?
SELECT * FROM T1 WHERE SUBSTING(NAME,2,1)=’L’?
SELECT * FROM T1 WHERE NAME LIKE ‘L%’?
即使NAME字段建有索引，前兩個查詢依舊無法利用索引完畢加快操作。引擎不得不正確全表全部數據逐條操作來完畢任務。而第三個查詢能夠使用索引來加快操作。

6.必要時強制查詢優化器使用某個索引，如在 where 子句中使用參數。也會導致全表掃描。

由於SQL僅僅有在運行時才會解析局部變量。但優化程序不能將訪問計劃的選擇推遲到運行時。它必須在編譯時進行選擇。然而，假設在編譯時建立訪問計劃，變量的值還是未知的。因而無法作為索引選擇的輸入項。如以下語句將進行全表掃描：
select id from t where?num=@num
能夠改為強制查詢使用索引：
select id from t with(index(索引名)) where?num=@num

7.應盡量避免在 where 子句中對字段進行表達式操作。這將導致引擎放棄使用索引而進行全表掃描。

如：
SELECT * FROM T1 WHERE F1/2=100?
應改為:?
SELECT * FROM T1 WHERE F1=100*2

SELECT * FROM RECORD WHERE SUBSTRING(CARD_NO,1,4)=’5378’?
應改為:?
SELECT * FROM RECORD WHERE CARD_NO LIKE ‘5378%’

SELECT member_number, first_name, last_name FROM members?
WHERE DATEDIFF(yy,datofbirth,GETDATE()) > 21?
應改為:?
SELECT member_number, first_name, last_name FROM members?
WHERE dateofbirth < DATEADD(yy,-21,GETDATE())?
即：不論什麽對列的操作都將導致表掃描，它包含數據庫函數、計算表達式等等，查詢時要盡可能將操作移至等號右邊。

8.應盡量避免在where子句中對字段進行函數操作，這將導致引擎放棄使用索引而進行全表掃描。

如：
select id from t where substring(name,1,3)=‘abc‘--name以abc開頭的id
select id from t where datediff(day,createdate,‘2005-11-30‘)=0--‘2005-11-30’生成的id
應改為:
select id from t where name like ‘abc%‘
select id from t where createdate>=‘2005-11-30‘ and createdate<‘2005-12-1‘

9.不要在 where 子句中的“=”左邊進行函數、算術運算或其它表達式運算，否則系統將可能無法正確使用索引。

10.在使用索引字段作為條件時，假設該索引是復合索引，那麽必須使用到該索引中的第一個字段作為條件時才幹保證系統使用該索引，否則該索引將不會被使用，並且應盡可能的讓字段順序與索引順序相一致。

11.非常多時候用 exists是一個好的選擇：
elect num from a where num in(select num from b)
用以下的語句替換：
select num from a where exists(select 1 from b where num=a.num)

SELECT SUM(T1.C1)FROM T1 WHERE(?
(SELECT COUNT(*)FROM T2 WHERE T2.C2=T1.C2>0)?
SELECT SUM(T1.C1) FROM T1WHERE EXISTS(?
SELECT * FROM T2 WHERE T2.C2=T1.C2)?
兩者產生同樣的結果，可是後者的效率顯然要高於前者。由於後者不會產生大量鎖定的表掃描或是索引掃描。

假設你想校驗表裏是否存在某條紀錄。不要用count(*)那樣效率非常低，並且浪費server資源。能夠用EXISTS取代。

如：?
IF (SELECT COUNT(*) FROM table_name WHERE column_name = ‘xxx‘)?
能夠寫成：?
IF EXISTS (SELECT * FROM table_name WHERE column_name = ‘xxx‘)

常常須要寫一個T_SQL語句比較一個父結果集和子結果集。從而找到是否存在在父結果集中有而在子結果集中沒有的記錄，如：?
SELECT a.hdr_key FROM hdr_tbl a---- tbl a 表示tbl用別名a取代?
WHERE NOT EXISTS (SELECT * FROM dtl_tbl b WHERE a.hdr_key = b.hdr_key)?
SELECT a.hdr_key FROM hdr_tbl a?
LEFT JOIN dtl_tbl b ON a.hdr_key = b.hdr_key WHERE b.hdr_key IS NULL?
SELECT hdr_key FROM hdr_tbl?
WHERE hdr_key NOT IN (SELECT hdr_key FROM dtl_tbl)?
三種寫法都能夠得到同樣正確的結果，可是效率依次降低。

12.盡量使用表變量來取代暫時表。假設表變量包含大量數據，請註意索引非常有限（僅僅有主鍵索引）。

13.避免頻繁創建和刪除暫時表。以降低系統表資源的消耗。

14.暫時表並非不可使用，適當地使用它們能夠使某些例程更有效。比如。當須要重復引用大型表或常常使用表中的某個數據集時。可是，對於一次性事件。最好使用導出表。

15.在新建暫時表時，假設一次性插入數據量非常大。那麽能夠使用 select into 取代 create table。避免造成大量 log ，以提高速度。假設數據量不大。為了緩和系統表的資源。應先create table。然後insert。

16.假設使用到了暫時表，在存儲過程的最後務必將全部的暫時表顯式刪除。先 truncate table 。然後 drop table ，這樣能夠避免系統表的較長時間鎖定。?
17.在全部的存儲過程和觸發器的開始處設置 SET NOCOUNT ON ，在結束時設置 SET NOCOUNT OFF 。

無需在運行存儲過程和觸發器的每一個語句後向client發送 DONE_IN_PROC 消息。

18.盡量避免大事務操作，提高系統並發能力。

19.盡量避免向client返回大數據量，若數據量過大。應該考慮相應需求是否合理。

?
20. 避免使用不兼容的數據類型。比如float和int、char和varchar、binary和varbinary是不兼容的。數據類型的不兼容可能使優化器無法運行一些本來能夠進行的優化操作。

比如:?
SELECT name FROM employee WHERE salary > 60000?
在這條語句中,如salary字段是money型的,則優化器非常難對其進行優化,由於60000是個整型數。我們應當在編程時將整型轉化成為錢幣型,而不要等到運行時轉化。

21.充分利用連接條件，在某種情況下。兩個表之間可能不僅僅一個的連接條件，這時在 WHERE 子句中將連接條件完整的寫上，有可能大大提高查詢速度。?
例：?
SELECT SUM(A.AMOUNT) FROM ACCOUNT A,CARD B WHERE A.CARD_NO = B.CARD_NO?
SELECT SUM(A.AMOUNT) FROM ACCOUNT A,CARD B WHERE A.CARD_NO = B.CARD_NO AND A.ACCOUNT_NO=B.ACCOUNT_NO?
第二句將比第一句運行快得多。

22、使用視圖加速查詢?
把表的一個子集進行排序並創建視圖，有時能加速查詢。它有助於避免多重排序 操作，並且在其它方面還能簡化優化器的工作。比如：
SELECT cust.name。rcvbles.balance，……other columns?
FROM cust，rcvbles?
WHERE cust.customer_id = rcvlbes.customer_id?
AND rcvblls.balance>0?
AND cust.postcode>“98000”?
ORDER BY cust.name

假設這個查詢要被運行多次而不止一次，能夠把全部未付款的客戶找出來放在一個視圖中。並按客戶的名字進行排序：?
CREATE VIEW DBO.V_CUST_RCVLBES?
AS?
SELECT cust.name，rcvbles.balance。……other columns?
FROM cust，rcvbles?
WHERE cust.customer_id = rcvlbes.customer_id?
AND rcvblls.balance>0?
ORDER BY cust.name?
然後以以下的方式在視圖中查詢：?
SELECT ＊ FROM V_CUST_RCVLBES?
WHERE postcode>“98000”?
視圖中的行要比主表中的行少，並且物理順序就是所要求的順序，降低了磁盤I/O。所以查詢工作量能夠得到大幅降低。

23、能用DISTINCT的就不用GROUP BY?
SELECT OrderID FROM Details WHERE UnitPrice > 10 GROUP BY OrderID?
可改為：?
SELECT DISTINCT OrderID FROM Details WHERE UnitPrice > 10

24.能用UNION ALL就不要用UNION?
UNION ALL不運行SELECT DISTINCT函數。這樣就會降低非常多不必要的資源?
35.盡量不要用SELECT INTO語句。

?
SELECT INOT 語句會導致表鎖定。阻止其它用戶訪問該表。

????上面我們提到的是一些主要的提高查詢速度的註意事項,可是在很多其它的情況下,往往須要重復試驗比較不同的語句以得到最佳方案。

最好的方法當然是測試，看實現同樣功能的SQL語句哪個運行時間最少，可是數據庫中假設數據量非常少。是比較不出來的，這時能夠用查看運行計劃。即：把實現同樣功能的多條SQL語句考到查詢分析器，按CTRL+L看查所利用的索引，表掃描次數（這兩個對性能影響最大），整體上看詢成本百分比就可以。?
三、算法的優化

盡量避免使用遊標，由於遊標的效率較差。假設遊標操作的數據超過1萬行。那麽就應該考慮改寫。.使用基於遊標的方法或暫時表方法之前。應先尋找基於集的解決方式來解決這個問題，基於集的方法通常更有效。

與暫時表一樣，遊標並非不可使用。對小型數據集使用 FAST_FORWARD 遊標通常要優於其它逐行處理方法，尤其是在必須引用幾個表才幹獲得所需的數據時。

在結果集中包含“合計”的例程通常要比使用遊標運行的速度快。假設開發時間同意，基於遊標的方法和基於集的方法都能夠嘗試一下，看哪一種方法的效果更好。
　　遊標提供了對特定集合中逐行掃描的手段。一般使用遊標逐行遍歷數據，依據取出的數據不同條件進行不同的操作。尤其對多表和大表定義的遊標（大的數據集合）循環非常easy使程序進入一個漫長的等特甚至死機。?
　 在有些場合，有時也非得使用遊標。此時也可考慮將符合條件的數據行轉入暫時表中，再對暫時表定義遊標進行操作。可時性能得到明顯提高。
（比如：對內統計第一版）
封裝存儲過程

四、建立高效的索引

　 創建索引一般有以下兩個目的：維護被索引列的唯一性和提供高速訪問表中數據的策略。

大型數據庫有兩種索引即簇索引和非簇索引。一個沒有簇索引的表是按堆結構存儲數據。全部的數據均加入在表的尾部。而建立了簇索引的表。其數據在物理上會依照簇索引鍵的順序存儲，一個表僅僅同意有一個簇索引。因此。依據B樹結構，能夠理解加入不論什麽一種索引均能提高按索引列查詢的速度。但會降低插入、更新、刪除操作的性能，尤其是當填充因子（Fill Factor）較大時。所以對索引較多的表進行頻繁的插入、更新、刪除操作，建表和索引時因設置較小的填充因子，以便在各數據頁中留下較多的自由空間，降低頁切割及又一次組織的工作。

?
索引是從數據庫中獲取數據的最高效方式之中的一個。95% 的數據庫性能問題都能夠採用索引技術得到解決。作為一條規則，我通常對邏輯主鍵使用唯一的成組索引，對系統鍵（作為存儲過程）採用唯一的非成組索引，對不論什麽外鍵列[字段]採用非成組索引。

只是，索引就象是鹽，太多了菜就鹹了。

你得考慮數據庫的空間有多大，表怎樣進行訪問，還有這些訪問是否主要用作讀寫。?
實際上。您能夠把索引理解為一種特殊的文件夾。微軟的SQL SERVER提供了兩種索引：聚集索引（clustered index。也稱聚類索引、簇集索引）和非聚集索引（nonclustered index，也稱非聚類索引、非簇集索引）。

以下，我們舉例來說明一下聚集索引和非聚集索引的區別：?
其實。我們的漢語字典的正文本身就是一個聚集索引。比方，我們要查“安”字，就會非常自然地翻開字典的前幾頁。由於“安”的拼音是“an”。而依照拼音排序漢字的字典是以英文字母“a”開頭並以“z”結尾的。那麽“安”字就自然地排在字典的前部。

假設您翻完了全部以“a”開頭的部分仍然找不到這個字。那麽就說明您的字典中沒有這個字；同樣的，假設查“張”字，那您也會將您的字典翻到最後部分，由於“張”的拼音是“zhang”。也就是說，字典的正文部分本身就是一個文件夾，您不須要再去查其它文件夾來找到您須要找的內容。?
我們把這樣的正文內容本身就是一種依照一定規則排列的文件夾稱為“聚集索引”。?
假設您認識某個字，您能夠高速地從自己主動中查到這個字。但您也可能會遇到您不認識的字。不知道它的發音，這時候，您就不能依照剛才的方法找到您要查的字，而須要去依據“偏旁部首”查到您要找的字。然後依據這個字後的頁碼直接翻到某頁來找到您要找的字。但您結合“部首文件夾”和“檢字表”而查到的字的排序並非真正的正文的排序方法。比方您查“張”字，我們能夠看到在查部首之後的檢字表中“張”的頁碼是672頁，檢字表中“張”的上面是“馳”字，但頁碼卻是63頁，“張”的以下是“弩”字，頁面是390頁。非常顯然，這些字並非真正的分別位於“張”字的上下方，如今您看到的連續的“馳、張、弩”三字實際上就是他們在非聚集索引中的排序。是字典正文中的字在非聚集索引中的映射。我們能夠通過這樣的方式來找到您所須要的字，但它須要兩個過程，先找到文件夾中的結果。然後再翻到您所須要的頁碼。

?
我們把這樣的文件夾純粹是文件夾，正文純粹是正文的排序方式稱為“非聚集索引”。

?
進一步引申一下，我們能夠非常easy的理解：每一個表僅僅能有一個聚集索引。由於文件夾僅僅能依照一種方法進行排序。

（一）何時使用聚集索引或非聚集索引?
以下的表總結了何時使用聚集索引或非聚集索引（非常重要）。?
動作描寫敘述 使用聚集索引 使用非聚集索引?
列常常被分組排序 應 應?
返回某範圍內的數據 應 不應?
一個或極少不同值 不應 不應?
小數目的不同值 應 不應?
大數目的不同值 不應 應?
頻繁更新的列 不應 應?
外鍵列 應 應?
主鍵列 應 應?
頻繁改動索引列 不應 應

其實，我們能夠通過前面聚集索引和非聚集索引的定義的樣例來理解上表。如：返回某範圍內的數據一項。比方您的某個表有一個時間列。恰好您把聚合索引建立在了該列，這時您查詢2004年1月1日至2004年10月1日之間的全部數據時。這個速度就將是非常快的，由於您的這本字典正文是按日期進行排序的，聚類索引僅僅須要找到要檢索的全部數據中的開頭和結尾數據就可以；而不像非聚集索引，必須先查到文件夾中查到每一項數據相應的頁碼。然後再依據頁碼查到詳細內容。

（二）結合實際。談索引使用的誤區

理論的目的是應用。盡管我們剛才列出了何時應使用聚集索引或非聚集索引，但在實踐中以上規則卻非常easy被忽視或不能依據實際情況進行綜合分析。以下我們將依據在實踐中遇到的實際問題來談一下索引使用的誤區，以便於大家掌握索引建立的方法。

?
1、主鍵就是聚集索引?
這樣的想法筆者覺得是極端錯誤的，是對聚集索引的一種浪費。

盡管SQL SERVER默認是在主鍵上建立聚集索引的。

?
通常，我們會在每一個表中都建立一個ID列，以區分每條數據，並且這個ID列是自己主動增大的，步長一般為1。我們的這個辦公自己主動化的實例中的列Gid就是如此。

此時。假設我們將這個列設為主鍵，SQL SERVER會將此列默覺得聚集索引。

這樣做有優點。就是能夠讓您的數據在數據庫中依照ID進行物理排序，但筆者覺得這樣做意義不大。

?
顯而易見，聚集索引的優勢是非常明顯的，而每一個表中僅僅能有一個聚集索引的規則。這使得聚集索引變得更加珍貴。

?
從我們前面談到的聚集索引的定義我們能夠看出，使用聚集索引的最大優點就是能夠依據查詢要求，迅速縮小查詢範圍，避免全表掃描。

在實際應用中，由於ID號是自己主動生成的。我們並不知道每條記錄的ID號，所以我們非常難在實踐中用ID號來進行查詢。

這就使讓ID號這個主鍵作為聚集索引成為一種資源浪費。

其次，讓每一個ID號都不同的字段作為聚集索引也不符合“大數目的不同值情況下不應建立聚合索引”規則；當然，這樣的情況僅僅是針對用戶常常改動記錄內容，特別是索引項的時候會負作用。但對於查詢速度並沒有影響。?
在辦公自己主動化系統中，不管是系統首頁顯示的須要用戶簽收的文件、會議還是用戶進行文件查詢等不論什麽情況下進行數據查詢都離不開字段的是“日期”還實用戶本身的“username”。

?
通常，辦公自己主動化的首頁會顯示每一個用戶尚未簽收的文件或會議。盡管我們的where語句能夠僅僅限制當前用戶尚未簽收的情況，但假設您的系統已建立了非常長時間。並且數據量非常大，那麽，每次每一個用戶打開首頁的時候都進行一次全表掃描，這樣做意義是不大的，絕大多數的用戶1個月前的文件都已經瀏覽過了，這樣做僅僅能徒增數據庫的開銷而已。

其實，我們全然能夠讓用戶打開系統首頁時，數據庫僅僅查詢這個用戶近3個月來未閱覽的文件。通過“日期”這個字段來限制表掃描，提高查詢速度。假設您的辦公自己主動化系統已經建立的2年，那麽您的首頁顯示速度理論上將是原來速度8倍。甚至更快。

2、僅僅要建立索引就能顯著提高查詢速度?
其實。我們能夠發現上面的樣例中，第2、3條語句全然同樣，且建立索引的字段也同樣。不同的僅是前者在fariqi字段上建立的是非聚合索引。後者在此字段上建立的是聚合索引。但查詢速度卻有著天差地別。

所以，並非是在不論什麽字段上簡單地建立索引就能提高查詢速度。
從建表的語句中。我們能夠看到這個有著1000萬數據的表中fariqi字段有5003個不同記錄。

在此字段上建立聚合索引是再合適只是了。在現實中，我們每天都會發幾個文件。這幾個文件的發文日期就同樣，這全然符合建立聚集索引要求的：“既不能絕大多數都同樣，又不能僅僅有極少數同樣”的規則。

由此看來，我們建立“適當”的聚合索引對於我們提高查詢速度是非常重要的。

3、把全部須要提高查詢速度的字段都加進聚集索引，以提高查詢速度?
上面已經談到：在進行數據查詢時都離不開字段的是“日期”還實用戶本身的“username”。既然這兩個字段都是如此的重要，我們能夠把他們合並起來，建立一個復合索引（compound index）。?
非常多人覺得僅僅要把不論什麽字段加進聚集索引，就能提高查詢速度。也有人感到迷惑：假設把復合的聚集索引字段分開查詢。那麽查詢速度會減慢嗎？帶著這個問題，我們來看一下以下的查詢速度（結果集都是25萬條數據）：（日期列fariqi首先排在復合聚集索引的起始列，usernameneibuyonghu排在後列）?
我們能夠看到假設僅用聚集索引的起始列作為查詢條件和同一時候用到復合聚集索引的全部列的查詢速度是差點兒一樣的，甚至比用上全部的復合索引列還要略快（在查詢結果集數目一樣的情況下）；而假設僅用復合聚集索引的非起始列作為查詢條件的話。這個索引是不起不論什麽作用的。當然，語句1、2的查詢速度一樣是由於查詢的條目數一樣。假設復合索引的全部列都用上。並且查詢結果少的話。這樣就會形成“索引覆蓋”，因而性能能夠達到最優。

同一時候，請記住：不管您是否常常使用聚合索引的其它列，但其前導列一定要是使用最頻繁的列。

（三）其它註意事項?
“水可載舟。亦可覆舟”。索引也一樣。索引有助於提高檢索性能，但過多或不當的索引也會導致系統低效。由於用戶在表中每加進一個索引。數據庫就要做很多其它的工作。

過多的索引甚至會導致索引碎片。?
所以說，我們要建立一個“適當”的索引體系，特別是對聚合索引的創建，更應精益求精，以使您的數據庫能得到高性能的發揮

大數據量高並發訪問的數據庫優化方法