[轉]淺析大數據量高併發的數據庫優化

連接：http://www.uml.org.cn/sjjm/201308264.asp

 

高併發數據庫能夠同時處理海量信息，應用範圍很廣。今天咱們將討論的是大數據量高併發的數據庫優化，但願對你們有所幫助。

1、數據庫結構的設計

若是不能設計一個合理的數據庫模型，不只會增長客戶端和服務器段程序的編程和維護的難度，並且將會影響系統實際運行的性能。因此，在一個系統開始實施以前，完備的數據庫模型的設計是必須的。

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

因此在考慮整個系統的流程的時候，咱們必需要考慮，在高併發大數據量的訪問狀況下，咱們的系統會不會出現極端的狀況。（例如：對外統計系統在7月16日出現的數據異常的狀況，併發大數據量的的訪問形成，數據庫的響應時間不能跟上數據刷新的速度形成。具體狀況是：在日期臨界時（00：00：00），判斷數據庫中是否有當前日期的記錄，沒有則插入一條當前日期的記錄。在低併發訪問的狀況下，不會發生問題，可是當日期臨界時的訪問量至關大的時候，在作這一判斷的時候，會出現屢次條件成立，則數據庫裏會被插入多條當前日期的記錄，從而形成數據錯誤。），數據庫的模型肯定下來以後，咱們有必要作一個系統內數據流向圖，分析可能出現的瓶頸。

爲了保證數據庫的一致性和完整性，在邏輯設計的時候每每會設計過多的表間關聯，儘量的下降數據的冗餘。（例如用戶表的地區，咱們能夠把地區另外存放到一個地區表中）若是數據冗餘低，數據的完整性容易獲得保證，提升了數據吞吐速度，保證了數據的完整性，清楚地表達數據元素之間的關係。而對於多表之間的關聯查詢（尤爲是大數據表）時，其性能將會下降，同時也提升了客戶端程序的編程難度，所以，物理設計需折衷考慮，根據業務規則，肯定對關聯表的數據量大小、數據項的訪問頻度，對此類數據表頻繁的關聯查詢應適當提升數據冗餘設計但增長了表間鏈接查詢的操做，也使得程序的變得複雜，爲了提升系統的響應時間，合理的數據冗餘也是必要的。設計人員在設計階段應根據系統操做的類型、頻度加以均衡考慮。

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

原來的表格必須能夠經過由它分離出去的表格從新構建。使用這個規定的好處是，你能夠確保不會在分離的表格中引入多餘的列，全部你建立的表格結構都與它們的實際須要同樣大。應用這條規定是一個好習慣，不過除非你要處理一個很是大型的數據，不然你將不須要用到它。（例如一個通行證系統，我能夠將 USERID，USERNAME，USERPASSWORD，單獨出來做個表，再把USERID做爲其餘表的外鍵）

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

一、數據行的長度不要超過8020字節，若是超過這個長度的話在物理頁中這條數據會佔用兩行從而形成存儲碎片，下降查詢效率。

二、可以用數字類型的字段儘可能選擇數字類型而不用字符串類型的（電話號碼），這會下降查詢和鏈接的性能，並會增長存儲開銷。這是由於引擎在處理查詢和鏈接回逐個比較字符串中每個字符，而對於數字型而言只須要比較一次就夠了。

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

四、字段的長度在最大限度的知足可能的須要的前提下，應該儘量的設得短一些，這樣能夠提升查詢的效率，並且在創建索引的時候也能夠減小資源的消耗。

2、查詢的優化

保證在實現功能的基礎上，儘可能減小對數據庫的訪問次數；經過搜索參數，儘可能減小對錶的訪問行數,最小化結果集，從而減輕網絡負擔；可以分開的操做盡可能分開處理，提升每次的響應速度；在數據窗口使用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 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(*)那樣效率很低，並且浪費服務器資源。能夠用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

第二句將比第一句執行快得多。

2二、使用視圖加速查詢
把表的一個子集進行排序並建立視圖，有時能加速查詢。它有助於避免多重排序 操做，並且在其餘方面還能簡化優化器的工做。例如：

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，因此查詢工做量能夠獲得大幅減小。

2三、能用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看查所利用的索引，表掃描次數（這兩個對性能影響最大），整體上看詢成本百分比便可。