一、數(shù)據(jù)庫結(jié)構(gòu)的設(shè)計(jì)

如果不能設(shè)計(jì)一個(gè)合理的數(shù)據(jù)庫模型，不僅會(huì)增加客戶端和服務(wù)器段程序的編程和維護(hù)的難度，而且將會(huì)影響系統(tǒng)實(shí)際運(yùn)行的性能。所以，在一個(gè)系統(tǒng)開始實(shí)施之前，完備的數(shù)據(jù)庫模型的設(shè)計(jì)是必須的。

在一個(gè)系統(tǒng)分析、設(shè)計(jì)階段，因?yàn)閿?shù)據(jù)量較小，負(fù)荷較低。我們往往只注意到功能的實(shí)現(xiàn)，而很難注意到性能的薄弱之處，等到系統(tǒng)投入實(shí)際運(yùn)行一段時(shí)間后，才發(fā)現(xiàn)系統(tǒng)的性能在降低，這時(shí)再來考慮提高系統(tǒng)性能則要花費(fèi)更多的人力物力，而整個(gè)系統(tǒng)也不可避免的形成了一個(gè)打補(bǔ)丁工程。

所以在考慮整個(gè)系統(tǒng)的流程的時(shí)候，我們必須要考慮，在高并發(fā)大數(shù)據(jù)量的訪問情況下，我們的系統(tǒng)會(huì)不會(huì)出現(xiàn)極端的情況。（例如：對(duì)外統(tǒng)計(jì)系統(tǒng)在7月16日出現(xiàn)的數(shù)據(jù)異常的情況，并發(fā)大數(shù)據(jù)量的的訪問造成，數(shù)據(jù)庫的響應(yīng)時(shí)間不能跟上數(shù)據(jù)刷新的速度造成。具體情況是：在日期臨界時(shí)（00：00：00），判斷數(shù)據(jù)庫中是否有當(dāng)前日期的記錄，沒有則插入一條當(dāng)前日期的記錄。在低并發(fā)訪問的情況下，不會(huì)發(fā)生問題，但是當(dāng)日期臨界時(shí)的訪問量相當(dāng)大的時(shí)候，在做這一判斷的時(shí)候，會(huì)出現(xiàn)多次條件成立，則數(shù)據(jù)庫里會(huì)被插入多條當(dāng)前日期的記錄，從而造成數(shù)據(jù)錯(cuò)誤。），數(shù)據(jù)庫的模型確定下來之后，我們有必要做一個(gè)系統(tǒng)內(nèi)數(shù)據(jù)流向圖，分析可能出現(xiàn)的瓶頸。

為了保證數(shù)據(jù)庫的一致性和完整性，在邏輯設(shè)計(jì)的時(shí)候往往會(huì)設(shè)計(jì)過多的表間關(guān)聯(lián)，盡可能的降低數(shù)據(jù)的冗余。（例如用戶表的地區(qū)，我們可以把地區(qū)另外存放到一個(gè)地區(qū)表中）如果數(shù)據(jù)冗余低，數(shù)據(jù)的完整性容易得到保證，提高了數(shù)據(jù)吞吐速度，保證了數(shù)據(jù)的完整性，清楚地表達(dá)數(shù)據(jù)元素之間的關(guān)系。而對(duì)于多表之間的關(guān)聯(lián)查詢（尤其是大數(shù)據(jù)表）時(shí)，其性能將會(huì)降低，同時(shí)也提高了客戶端程序的編程難度，因此，物理設(shè)計(jì)需折衷考慮，根據(jù)業(yè)務(wù)規(guī)則，確定對(duì)關(guān)聯(lián)表的數(shù)據(jù)量大小、數(shù)據(jù)項(xiàng)的訪問頻度，對(duì)此類數(shù)據(jù)表頻繁的關(guān)聯(lián)查詢應(yīng)適當(dāng)提高數(shù)據(jù)冗余設(shè)計(jì)但增加了表間連接查詢的操作，也使得程序的變得復(fù)雜，為了提高系統(tǒng)的響應(yīng)時(shí)間，合理的數(shù)據(jù)冗余也是必要的。設(shè)計(jì)人員在設(shè)計(jì)階段應(yīng)根據(jù)系統(tǒng)操作的類型、頻度加以均衡考慮。

另外，***不要用自增屬性字段作為主鍵與子表關(guān)聯(lián)。不便于系統(tǒng)的遷移和數(shù)據(jù)恢復(fù)。對(duì)外統(tǒng)計(jì)系統(tǒng)映射關(guān)系丟失（******************）。

原來的表格必須可以通過由它分離出去的表格重新構(gòu)建。使用這個(gè)規(guī)定的好處是，你可以確保不會(huì)在分離的表格中引入多余的列，所有你創(chuàng)建的表格結(jié)構(gòu)都與它們的實(shí)際需要一樣大。應(yīng)用這條規(guī)定是一個(gè)好習(xí)慣，不過除非你要處理一個(gè)非常大型的數(shù)據(jù)，否則你將不需要用到它。（例如一個(gè)通行證系統(tǒng)，我可以將 USERID，USERNAME，USERPASSWORD，單獨(dú)出來作個(gè)表，再把USERID作為其他表的外鍵）

表的設(shè)計(jì)具體注意的問題：

1、數(shù)據(jù)行的長度不要超過8020字節(jié)，如果超過這個(gè)長度的話在物理頁中這條數(shù)據(jù)會(huì)占用兩行從而造成存儲(chǔ)碎片，降低查詢效率。

2、能夠用數(shù)字類型的字段盡量選擇數(shù)字類型而不用字符串類型的（電話號(hào)碼），這會(huì)降低查詢和連接的性能，并會(huì)增加存儲(chǔ)開銷。這是因?yàn)橐嬖谔幚聿樵兒瓦B接回逐個(gè)比較字符串中每一個(gè)字符，而對(duì)于數(shù)字型而言只需要比較一次就夠了。

3、對(duì)于不可變字符類型char和可變字符類型varchar 都是8000字節(jié),char查詢快，但是耗存儲(chǔ)空間，varchar查詢相對(duì)慢一些但是節(jié)省存儲(chǔ)空間。在設(shè)計(jì)字段的時(shí)候可以靈活選擇，例如用戶名、密碼等長度變化不大的字段可以選擇CHAR，對(duì)于評(píng)論等長度變化大的字段可以選擇VARCHAR。

4、字段的長度在***限度的滿足可能的需要的前提下，應(yīng)該盡可能的設(shè)得短一些，這樣可以提高查詢的效率，而且在建立索引的時(shí)候也可以減少資源的消耗。

二、查詢的優(yōu)化

保證在實(shí)現(xiàn)功能的基礎(chǔ)上，盡量減少對(duì)數(shù)據(jù)庫的訪問次數(shù)；通過搜索參數(shù)，盡量減少對(duì)表的訪問行數(shù),最小化結(jié)果集，從而減輕網(wǎng)絡(luò)負(fù)擔(dān)；能夠分開的操作盡量分開處理，提高每次的響應(yīng)速度；在數(shù)據(jù)窗口使用SQL時(shí)，盡量把使用的索引放在選擇的首列；算法的結(jié)構(gòu)盡量簡單；在查詢時(shí)，不要過多地使用通配符如 Select * FROM T1語句，要用到幾列就選擇幾列如：Select COL1,COL2 FROM T1；在可能的情況下盡量限制盡量結(jié)果集行數(shù)如：Select TOP 300 COL1,COL2,COL3 FROM T1,因?yàn)槟承┣闆r下用戶是不需要那么多的數(shù)據(jù)的。 

在沒有建索引的情況下，數(shù)據(jù)庫查找某一條數(shù)據(jù)，就必須進(jìn)行全表掃描了，對(duì)所有數(shù)據(jù)進(jìn)行一次遍歷，查找出符合條件的記錄。在數(shù)據(jù)量比較小的情況下，也許看不出明顯的差別，但是當(dāng)數(shù)據(jù)量大的情況下，這種情況就是極為糟糕的了。

SQL語句在SQL SERVER中是如何執(zhí)行的，他們擔(dān)心自己所寫的SQL語句會(huì)被SQL SERVER誤解。比如：

select * from table1 where name='zhangsan' and tID > 10000 

和執(zhí)行:

select * from table1 where tID > 10000 and name='zhangsan' 

一些人不知道以上兩條語句的執(zhí)行效率是否一樣，因?yàn)槿绻唵蔚膹恼Z句先后上看，這兩個(gè)語句的確是不一樣，如果tID是一個(gè)聚合索引，那么后一句僅僅從表的 10000條以后的記錄中查找就行了；而前一句則要先從全表中查找看有幾個(gè)name='zhangsan'的，而后再根據(jù)限制條件條件tID> 10000來提出查詢結(jié)果。

事實(shí)上，這樣的擔(dān)心是不必要的。SQL SERVER中有一個(gè)“查詢分析優(yōu)化器”，它可以計(jì)算出where子句中的搜索條件并確定哪個(gè)索引能縮小表掃描的搜索空間，也就是說，它能實(shí)現(xiàn)自動(dòng)優(yōu)化。雖然查詢優(yōu)化器可以根據(jù)where子句自動(dòng)的進(jìn)行查詢優(yōu)化，但有時(shí)查詢優(yōu)化器就會(huì)不按照您的本意進(jìn)行快速查詢。

在查詢分析階段，查詢優(yōu)化器查看查詢的每個(gè)階段并決定限制需要掃描的數(shù)據(jù)量是否有用。如果一個(gè)階段可以被用作一個(gè)掃描參數(shù)（SARG），那么就稱之為可優(yōu)化的，并且可以利用索引快速獲得所需數(shù)據(jù)。

SARG的定義：用于限制搜索的一個(gè)操作，因?yàn)樗ǔＪ侵敢粋€(gè)特定的匹配，一個(gè)值的范圍內(nèi)的匹配或者兩個(gè)以上條件的AND連接。形式如下：

列名 操作符 <常數(shù) 或 變量> 或 <常數(shù) 或 變量> 操作符 列名
列名可以出現(xiàn)在操作符的一邊，而常數(shù)或變量出現(xiàn)在操作符的另一邊。如：
Name=’張三’
價(jià)格>5000
5000<價(jià)格
Name=’張三’ and 價(jià)格>5000

如果一個(gè)表達(dá)式不能滿足SARG的形式，那它就無法限制搜索的范圍了，也就是SQL SERVER必須對(duì)每一行都判斷它是否滿足Where子句中的所有條件。所以一個(gè)索引對(duì)于不滿足SARG形式的表達(dá)式來說是無用的。

所以，優(yōu)化查詢最重要的就是，盡量使語句符合查詢優(yōu)化器的規(guī)則避免全表掃描而使用索引查詢。

具體要注意的：

1.應(yīng)盡量避免在 where 子句中對(duì)字段進(jìn)行 null 值判斷，否則將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描，如：

select id from t where num is null 

可以在num上設(shè)置默認(rèn)值0，確保表中num列沒有null值，然后這樣查詢：

select id from t where num=0 

2.應(yīng)盡量避免在 where 子句中使用!=或<>操作符，否則將引擎放棄使用索引而進(jìn)行全表掃描。優(yōu)化器將無法通過索引來確定將要命中的行數(shù),因此需要搜索該表的所有行。

3.應(yīng)盡量避免在 where 子句中使用 or 來連接條件，否則將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描，如：

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 也要慎用，因?yàn)镮N會(huì)使系統(tǒng)無法使用索引,而只能直接搜索表中的數(shù)據(jù)。如：

select id from t where num in(1,2,3) 

對(duì)于連續(xù)的數(shù)值，能用 between 就不要用 in 了：

select id from t where num between 1 and 3 

5.盡量避免在索引過的字符數(shù)據(jù)中，使用非打頭字母搜索。這也使得引擎無法利用索引。

見如下例子：

Select * FROM T1 Where NAME LIKE ‘%L%’  
Select * FROM T1 Where SUBSTING(NAME,2,1)=’L’  
Select * FROM T1 Where NAME LIKE ‘L%’ 

即使NAME字段建有索引，前兩個(gè)查詢依然無法利用索引完成加快操作，引擎不得不對(duì)全表所有數(shù)據(jù)逐條操作來完成任務(wù)。而第三個(gè)查詢能夠使用索引來加快操作。

6.必要時(shí)強(qiáng)制查詢優(yōu)化器使用某個(gè)索引，如在 where 子句中使用參數(shù)，也會(huì)導(dǎo)致全表掃描。因?yàn)镾QL只有在運(yùn)行時(shí)才會(huì)解析局部變量，但優(yōu)化程序不能將訪問計(jì)劃的選擇推遲到運(yùn)行時(shí)；它必須在編譯時(shí)進(jìn)行選擇。然而，如果在編譯時(shí)建立訪問計(jì)劃，變量的值還是未知的，因而無法作為索引選擇的輸入項(xiàng)。如下面語句將進(jìn)行全表掃描：可以改為強(qiáng)制查詢使用索引：

select id from t with(index(索引名)) where num=@num 

7.應(yīng)盡量避免在 where 子句中對(duì)字段進(jìn)行表達(dá)式操作，這將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描。如：
 

Select * FROM T1 Where F1/2=100 

應(yīng)改為:

Select * FROM T1 Where F1=100*2  
Select * FROM RECORD Where SUBSTRING(CARD_NO,1,4)=’5378’ 

應(yīng)改為:

Select * FROM RECORD Where CARD_NO LIKE ‘5378%’  
Select member_number, first_name, last_name FROM members  
Where DATEDIFF(yy,datofbirth,GETDATE()) > 21 

應(yīng)改為:

Select member_number, first_name, last_name FROM members  
Where dateofbirth < DATEADD(yy,-21,GETDATE()) 

即：任何對(duì)列的操作都將導(dǎo)致表掃描，它包括數(shù)據(jù)庫函數(shù)、計(jì)算表達(dá)式等等，查詢時(shí)要盡可能將操作移至等號(hào)右邊。

8.應(yīng)盡量避免在where子句中對(duì)字段進(jìn)行函數(shù)操作，這將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描。如：

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 

應(yīng)改為:

select id from t where name like 'abc%' 
select id from t where createdate>='2005-11-30' and createdate<'2005-12-1' 

9.不要在 where 子句中的“=”左邊進(jìn)行函數(shù)、算術(shù)運(yùn)算或其他表達(dá)式運(yùn)算，否則系統(tǒng)將可能無法正確使用索引。

10.在使用索引字段作為條件時(shí)，如果該索引是復(fù)合索引，那么必須使用到該索引中的***個(gè)字段作為條件時(shí)才能保證系統(tǒng)使用該索引，否則該索引將不會(huì)被使用，并且應(yīng)盡可能的讓字段順序與索引順序相一致。

11.很多時(shí)候用 exists是一個(gè)好的選擇：

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) 

兩者產(chǎn)生相同的結(jié)果，但是后者的效率顯然要高于前者。因?yàn)楹笳卟粫?huì)產(chǎn)生大量鎖定的表掃描或是索引掃描。

如果你想校驗(yàn)表里是否存在某條紀(jì)錄，不要用count(*)那樣效率很低，而且浪費(fèi)服務(wù)器資源?？梢杂肊XISTS代替。如：

IF (Select COUNT(*) FROM table_name Where column_name = 'xxx') 

可以寫成：

IF EXISTS (Select * FROM table_name Where column_name = 'xxx') 

經(jīng)常需要寫一個(gè)T_SQL語句比較一個(gè)父結(jié)果集和子結(jié)果集，從而找到是否存在在父結(jié)果集中有而在子結(jié)果集中沒有的記錄，如：

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) 

三種寫法都可以得到同樣正確的結(jié)果，但是效率依次降低。

12.盡量使用表變量來代替臨時(shí)表。如果表變量包含大量數(shù)據(jù)，請(qǐng)注意索引非常有限（只有主鍵索引）。

13.避免頻繁創(chuàng)建和刪除臨時(shí)表，以減少系統(tǒng)表資源的消耗。

14.臨時(shí)表并不是不可使用，適當(dāng)?shù)厥褂盟鼈兛梢允鼓承├谈行В?，?dāng)需要重復(fù)引用大型表或常用表中的某個(gè)數(shù)據(jù)集時(shí)。但是，對(duì)于一次性事件，***使用導(dǎo)出表。

15.在新建臨時(shí)表時(shí)，如果一次性插入數(shù)據(jù)量很大，那么可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果數(shù)據(jù)量不大，為了緩和系統(tǒng)表的資源，應(yīng)先create table，然后insert。

16.如果使用到了臨時(shí)表，在存儲(chǔ)過程的***務(wù)必將所有的臨時(shí)表顯式刪除，先 truncate table ，然后 drop table ，這樣可以避免系統(tǒng)表的較長時(shí)間鎖定。

17.在所有的存儲(chǔ)過程和觸發(fā)器的開始處設(shè)置 SET NOCOUNT ON ，在結(jié)束時(shí)設(shè)置 SET NOCOUNT OFF 。無需在執(zhí)行存儲(chǔ)過程和觸發(fā)器的每個(gè)語句后向客戶端發(fā)送 DONE_IN_PROC 消息。

18.盡量避免大事務(wù)操作，提高系統(tǒng)并發(fā)能力。

19.盡量避免向客戶端返回大數(shù)據(jù)量，若數(shù)據(jù)量過大，應(yīng)該考慮相應(yīng)需求是否合理。

20. 避免使用不兼容的數(shù)據(jù)類型。例如float和int、char和varchar、binary和varbinary是不兼容的。數(shù)據(jù)類型的不兼容可能使優(yōu)化器無法執(zhí)行一些本來可以進(jìn)行的優(yōu)化操作。例如:

Select name FROM employee Where salary > 60000 

在這條語句中,如salary字段是money型的,則優(yōu)化器很難對(duì)其進(jìn)行優(yōu)化,因?yàn)?0000是個(gè)整型數(shù)。我們應(yīng)當(dāng)在編程時(shí)將整型轉(zhuǎn)化成為錢幣型,而不要等到運(yùn)行時(shí)轉(zhuǎn)化。

21.充分利用連接條件，在某種情況下，兩個(gè)表之間可能不只一個(gè)的連接條件，這時(shí)在 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 

第二句將比***句執(zhí)行快得多。

22、使用視圖加速查詢
把表的一個(gè)子集進(jìn)行排序并創(chuàng)建視圖，有時(shí)能加速查詢。它有助于避免多重排序 操作，而且在其他方面還能簡化優(yōu)化器的工作。例如：

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 

如果這個(gè)查詢要被執(zhí)行多次而不止一次，可以把所有未付款的客戶找出來放在一個(gè)視圖中，并按客戶的名字進(jìn)行排序：

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不執(zhí)行Select DISTINCT函數(shù)，這樣就會(huì)減少很多不必要的資源

35.盡量不要用Select INTO語句。

Select INOT 語句會(huì)導(dǎo)致表鎖定，阻止其他用戶訪問該表。

上面我們提到的是一些基本的提高查詢速度的注意事項(xiàng),但是在更多的情況下,往往需要反復(fù)試驗(yàn)比較不同的語句以得到***方案。***的方法當(dāng)然是測(cè)試，看實(shí)現(xiàn)相同功能的SQL語句哪個(gè)執(zhí)行時(shí)間最少，但是數(shù)據(jù)庫中如果數(shù)據(jù)量很少，是比較不出來的，這時(shí)可以用查看執(zhí)行計(jì)劃，即：把實(shí)現(xiàn)相同功能的多條SQL語句考到查詢分析器，按CTRL+L看查所利用的索引，表掃描次數(shù)（這兩個(gè)對(duì)性能影響***），總體上看詢成本百分比即可。 

原文鏈接：http://www.cnblogs.com/falconfei/archive/2010/12/01/1892592.html

【編輯推薦】

1. IBM DB2中提高并發(fā)度的3個(gè)好用方案介紹
2. MySQL***高并發(fā)網(wǎng)站實(shí)戰(zhàn)攻略
3. PHP將數(shù)據(jù)從Oracle向MySQL數(shù)據(jù)遷移實(shí)例