一、數據庫結構的設計
如果不能設計一個合理的數據庫模型，不僅會增加客戶端和服務器段程序的編程和維護的難度，而且將會影響系統實際運行的性能。所以，在一個系統開始實施之前，完備的數據庫模型的設計是必須的。
在一個系統分析、設計階段，因為數據量較小，負荷較低。我們往往只注意到功能的實現，而很難注意到性能的薄弱之處，等到系統投入實際運行一段時間后，才發現系統的性能在降低，這時再來考慮提高系統性能則要花費更多的人力物力，而整個系統也不可避免的形成了一個打補丁工程。
所以在考慮整個系統的流程的時候，我們必須要考慮，在高并發大數據量的訪問情況下，我們的系統會不會出現極端的情況。（例如：對外統計系統在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語句，要用到幾列就選擇幾列如：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
第二句將比第一句執行快得多。
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看查所利用的索引，表掃描次數（這兩個對性能影響最大），總體上看詢成本百分比即可。
原文鏈接：http://www.cnblogs.com/falconfei/archive/2010/12/01/1892592.html
