mysql大資料高並發處理

標籤：資料窗   分析   事件   record   解決   會議   地區表   簡單   sub   

一、資料庫結構的設計

如果不能設計一個合理的資料庫模型，不僅會增加用戶端和伺服器段程式的編程和維護的難度，而且將會影響系統實際啟動並執行效能。所以，在一個系統開始實施之前，完備的資料庫模型的設計是必須的。

在一個系統分析、設計階段，因為資料量較小，負荷較低。我們往往只注意到功能的實現，而很難注意到效能的薄弱之處，等到系統投入實際運行一段時間後，才發現系統的效能在降低，這時再來考慮提高系統效能則要花費更多的人力物力，而整個系統也不可避免的形成了一個打補丁工程。

所以在考慮整個系統的流程的時候，我們必須要考慮，在高並發大資料量的訪問情況下，我們的系統會不會出現極端的情況。（例如：對外統計系統在7月16日出現的資料異常的情況，並發大資料量的的訪問造成，資料庫的回應時間不能跟上資料重新整理的速度造成。具體情況是：在日期臨界時（00：00：00），判斷資料庫中是否有當前日期的記錄，沒有則插入一條當前日期的記錄。在低並發訪問的情況下，不會發生問題，但是當日期臨界時的訪問量相當大的時候，在做這一判斷的時候，會出現多次條件成立，則資料庫裡會被插入多條當前日期的記錄，從而造成資料錯誤。），資料庫的模型確定下來之後，我們有必要做一個系統內資料流向圖，分析可能出現的瓶頸。

為了保證資料庫的一致性和完整性，在邏輯設計的時候往往會設計過多的表間關聯，儘可能的降低資料的冗餘。（例如使用者表的地區，我們可以把地區另外存放到一個地區表中）如果資料冗餘低，資料的完整性容易得到保證，提高了資料吞吐速度，保證了資料的完整性，清楚地表達資料元素之間的關係。而對於多表之間的關聯查詢（尤其是大資料表）時，其效能將會降低，同時也提高了用戶端程式的編程難度，因此，實體設計需折衷考慮，根據商務規則，確定對關聯表的資料量大小、資料項目的訪問頻度，對此類資料表頻繁的關聯查詢應適當提高資料冗餘設計但增加了表間串連查詢的操作，也使得程式的變得複雜，為了提高系統的回應時間，合理的資料冗餘也是必要的。設計人員在設計階段應根據系統操作的類型、頻度加以均衡考慮。

另外，最好不要用自增屬性欄位作為主鍵與子表關聯。不便於系統的遷移和資料恢複。對外統計系統映射關係丟失（******************）。

原來的表格必須可以通過由它分離出去的表格重新構建。使用這個規定的好處是，你可以確保不會在分離的表格中引入多餘的列，所有你建立的表格結構都與它們的實際需要一樣大。應用這條規定是一個好習慣，不過除非你要處理一個非常大型的資料，否則你將不需要用到它。（例如一個通行證系統，我可以將USERID，USERNAME，USERPASSWORD，單獨出來作個表，再把USERID作為其他表的外鍵）

表的設計具體注意的問題：

1、資料行的長度不要超過8020位元組，如果超過這個長度的話在物理頁中這條資料會佔用兩行從而造成儲存片段，降低查詢效率。

2、能夠用數字類型的欄位盡量選擇數字類型而不用字串類型的（電話號碼），這會降低查詢和串連的效能，並會增加儲存開銷。這是因為引擎在處理查詢和串連回逐個比較字串中每一個字元，而對於數字型而言只需要比較一次就夠了。

3、對於不可變字元類型char和可變字元類型varchar 都是8000位元組,char查詢快，但是耗儲存空間，varchar查詢相對慢一些但是節省儲存空間。在設計欄位的時候可以靈活選擇，例如使用者名稱、密碼等長度變化不大的欄位可以選擇CHAR，對於評論等長度變化大的欄位可以選擇VARCHAR。

4、欄位的長度在最大限度的滿足可能的需要的前提下，應該儘可能的設得短一些，這樣可以提高查詢的效率，而且在建立索引的時候也可以減少資源的消耗。

二、查詢的最佳化

保證在實現功能的基礎上，盡量減少對資料庫的訪問次數(可以用緩衝儲存查詢結果，減少查詢次數)；通過搜尋參數，盡量減少對錶的訪問行數,最小化結果集，從而減輕網路負擔；能夠分開的操作盡量分開處理，提高每次的響應速度；在資料視窗使用SQL時，盡量把使用的索引放在選擇的首列；演算法的結構盡量簡單；在查詢時，不要過多地使用萬用字元如SELECT * FROM T1語句，要用到幾列就選擇幾列如：SELECTCOL1,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 [email protected]

可以改為強制查詢使用索引：

select id from t with(index(索引名)) where [email protected]

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(*)那樣效率很低，而且浪費伺服器資源。可以用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 。無需在執行預存程序和觸發器的每個語句後向用戶端發送 DONE_IN_PROC 訊息。

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

19.盡量避免向用戶端返回大資料量，若資料量過大，應該考慮相應需求是否合理。

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 （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 遊標通常要優於其他逐行處理方法，尤其是在必須引用幾個表才能獲得所需的資料時。在結果集中包括“合計”的常式通常要比使用遊標執行的速度快。如果開發時間允許，基於遊標的方法和基於集的方法都可以嘗試一下，看哪一種方法的效果更好。

遊標提供了對特定集合中漸進式掃描的手段，一般使用遊標逐行遍曆資料，根據取出的資料不同條件進行不同的操作。尤其對多表和大表定義的遊標（大的資料集合）迴圈很容易使程式進入一個漫長的等特甚至死機。

在有些場合，有時也非得使用遊標，此時也可考慮將合格資料行轉入暫存資料表中，再對暫存資料表定義遊標進行操作，可時效能得到明顯提高。

（例如：對內統計第一版）

封裝預存程序

四、建立高效的索引

建立索引一般有以下兩個目的：維護被索引列的唯一性和提供快速存取表中資料的策略。大型資料庫有兩種索引即簇索引和非簇索引，一個沒有簇索引的表是按堆結構儲存資料，所有的資料均添加在表的尾部，而建立了簇索引的表，其資料在物理上會按照簇索引鍵的順序儲存，一個表只允許有一個簇索引，因此，根據B樹結構，可以理解添加任何一種索引均能提高按索引列查詢的速度，但會降低插入、更新、刪除操作的效能，尤其是當填滿因數（Fill Factor）較大時。所以對索引較多的表進行頻繁的插入、更新、刪除操作，建表和索引時因設定較小的填滿因數，以便在各資料頁中留下較多的自由空間，減少頁分割及重新組織的工作。

索引是從資料庫中擷取資料的最高效方式之一。95% 的資料庫效能問題都可以採用索引技術得到解決。作為一條規則，我通常對邏輯主鍵使用唯一的成組索引，對系統鍵（作為預存程序）採用唯一的非成組索引，對任何外鍵列[欄位]採用非成組索引。不過，索引就象是鹽，太多了菜就鹹了。你得考慮資料庫的空間有多大，表如何進行訪問，還有這些訪問是否主要用作讀寫。

實際上，您可以把索引理解為一種特殊的目錄。微軟的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進行物理排序，但筆者認為這樣做意義不大。

顯而易見，叢集索引的優勢是很明顯的，而每個表中只能有一個叢集索引的規則，這使得叢集索引變得更加珍貴。

從我們前面談到的叢集索引的定義我們可以看出，使用叢集索引的最大好處就是能夠根據查詢要求，迅速縮小查詢範圍，避免全表掃描。在實際應用中，因為ID號是自動產生的，我們並不知道每條記錄的ID號，所以我們很難在實踐中用ID號來進行查詢。這就使讓ID號這個主鍵作為叢集索引成為一種資源浪費。其次，讓每個ID號都不同的欄位作為叢集索引也不符合“大數目的不同值情況下不應建立彙總索引”規則；當然，這種情況只是針對使用者經常修改記錄內容，特別是索引項目的時候會負作用，但對於查詢速度並沒有影響。

在辦公自動化系統中，無論是系統首頁顯示的需要使用者簽收的檔案、會議還是使用者進行檔案查詢等任何情況下進行資料查詢都離不開欄位的是“日期”還有使用者本身的“使用者名稱”。

通常，辦公自動化的首頁會顯示每個使用者尚未簽收的檔案或會議。雖然我們的where語句可以僅僅限制目前使用者尚未簽收的情況，但如果您的系統已建立了很長時間，並且資料量很大，那麼，每次每個使用者開啟首頁的時候都進行一次全表掃描，這樣做意義是不大的，絕大多數的使用者1個月前的檔案都已經瀏覽過了，這樣做只能徒增資料庫的開銷而已。事實上，我們完全可以讓使用者開啟系統首頁時，資料庫僅僅查詢這個使用者近3個月來未閱覽的檔案，通過“日期”這個欄位來限制表掃描，提高查詢速度。如果您的辦公自動化系統已經建立的2年，那麼您的首頁顯示速度理論上將是原來速度8倍，甚至更快。

2、只要建立索引就能顯著提高查詢速度

事實上，我們可以發現上面的例子中，第2、3條語句完全相同，且建立索引的欄位也相同；不同的僅是前者在fariqi欄位上建立的是非彙總索引，後者在此欄位上建立的是彙總索引，但查詢速度卻有著天壤之別。所以，並非是在任何欄位上簡單地建立索引就能提高查詢速度。

從建表的語句中，我們可以看到這個有著1000萬資料的表中fariqi欄位有5003個不同記錄。在此欄位上建立彙總索引是再合適不過了。在現實中，我們每天都會發幾個檔案，這幾個檔案的發文日期就相同，這完全符合建立叢集索引要求的：“既不能絕大多數都相同，又不能只有極少數相同”的規則。由此看來，我們建立“適當”的彙總索引對於我們提高查詢速度是非常重要的。

3、把所有需要提高查詢速度的欄位都加進叢集索引，以提高查詢速度

上面已經談到：在進行資料查詢時都離不開欄位的是“日期”還有使用者本身的“使用者名稱”。既然這兩個欄位都是如此的重要，我們可以把他們合并起來，建立一個複合索引（compound index）。

很多人認為只要把任何欄位加進叢集索引，就能提高查詢速度，也有人感到迷惑：如果把複合的叢集索引欄位分開查詢，那麼查詢速度會減慢嗎？帶著這個問題，我們來看一下以下的查詢速度（結果集都是25萬條資料）：（日期列fariqi首先排在複合叢集索引的起始列，使用者名稱neibuyonghu排在後列）

我們可以看到如果僅用叢集索引的起始列作為查詢條件和同時用到複合叢集索引的全部列的查詢速度是幾乎一樣的，甚至比用上全部的複合索引列還要略快（在查詢結果集數目一樣的情況下）；而如果僅用複合叢集索引的非起始列作為查詢條件的話，這個索引是不起任何作用的。當然，語句1、2的查詢速度一樣是因為查詢的條目數一樣，如果複合索引的所有列都用上，而且查詢結果少的話，這樣就會形成“索引覆蓋”，因而效能可以達到最優。同時，請記住：無論您是否經常使用彙總索引的其他列，但其前置列一定要是使用最頻繁的列。

（三）其他注意事項

“水可載舟，亦可覆舟”，索引也一樣。索引有助於提高檢索效能，但過多或不當的索引也會導致系統低效。因為使用者在表中每加進一個索引，資料庫就要做更多的工作。過多的索引甚至會導致索引片段。

所以說，我們要建立一個“適當”的索引體系，特別是對彙總索引的建立，更應精益求精，以使您的資料庫能得到高效能的發揮

mysql大資料高並發處理（轉）