1、數據庫結構的設計
一、數據行的長度不要超過8020字節，若是超過這個長度的話在物理頁中這條數據會佔用兩行從而形成存儲碎片，下降查詢效率。html
二、可以用數字類型的字段儘可能選擇數字類型而不用字符串類型的（電話號碼），這會下降查詢和鏈接的性能，並會增長存儲開銷。這是由於引擎在處理查詢和鏈接會逐個比較字符串中每個字符，而對於數字型而言只須要比較一次就夠了。程序員
三、對於不可變字符類型char和可變字符類型varchar 都是8000字節,char查詢快，可是耗存儲空間，varchar查詢相對慢一些可是節省存儲空間。在設計字段的時候能夠靈活選擇，例如用戶名、密碼等長度變化不大的字段能夠選擇CHAR，對於評論等長度變化大的字段能夠選擇VARCHAR。面試
四、字段的長度在最大限度的知足可能的須要的前提下，應該儘量的設得短一些，這樣能夠提升查詢的效率，並且在創建索引的時候也能夠減小資源的消耗。算法
2、查詢的優化
保證在實現功能的基礎上，儘可能減小對數據庫的訪問次數(能夠用緩存保存查詢結果，減小查詢次數)；經過搜索參數，儘可能減小對錶的訪問行數,最小化結果集，從而減輕網絡負擔；可以分開的操做盡可能分開處理，提升每次的響應速度；在數據窗口使用SQL時，儘可能把使用的索引放在選擇的首列；算法的結構儘可能簡單；在查詢時，不要過多地使用通配符如SELECT * FROM T1語句，要用到幾列就選擇幾列如：SELECTCOL1,COL2 FROM T1；在可能的狀況下儘可能限制儘可能結果集行數如：SELECT TOP 300 COL1,COL2,COL3 FROM T1,由於某些狀況下用戶是不須要那麼多的數據的。數據庫
在沒有建索引的狀況下，數據庫查找某一條數據，就必須進行全表掃描了，對全部數據進行一次遍歷，查找出符合條件的記錄。在數據量比較小的狀況下，也許看不出明顯的差異，可是當數據量大的狀況下，這種狀況就是極爲糟糕的了。編程
一、應儘可能避免在 where 子句中對字段進行 null 值判斷，不然將致使引擎放棄使用索引而進行全表掃描，如：緩存
select id from t where num is null
能夠在num上設置默認值0，確保表中num列沒有null值，而後這樣查詢：
select id from t where num = 0
二、應儘可能避免在 where 子句中使用!=或<>操做符，不然將引擎放棄使用索引而進行全表掃描。優化器將沒法經過索引來肯定將要命中的行數,所以須要搜索該表的全部行。服務器
三、應儘可能避免在 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
四、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
五、儘可能避免在索引過的字符數據中，使用非打頭字母搜索。這也使得引擎沒法利用索引。
見以下例子：
SELECT * FROM T1 WHERE NAME LIKE‘ % L % ’ SELECT * FROM T1 WHERE SUBSTING(NAME, 2, 1) = ’L’ SELECT * FROM T1 WHERE NAME LIKE‘ L % ’
即便NAME字段建有索引，前兩個查詢依然沒法利用索引完成加快操做，引擎不得不對全表全部數據逐條操做來完成任務。而第三個查詢可以使用索引來加快操做。
六、必要時強制查詢優化器使用某個索引，如在 where 子句中使用參數，也會致使全表掃描。由於SQL只有在運行時纔會解析局部變量，但優化程序不能將訪問計劃的選擇推遲到運行時；它必須在編譯時進行選擇。然而，若是在編譯時創建訪問計劃，變量的值仍是未知的，於是沒法做爲索引選擇的輸入項。以下面語句將進行全表掃描：
select id from t where num = @num
能夠改成強制查詢使用索引：
select id from t with(index(索引名)) where num = @num
七、應儘可能避免在 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())
即：任何對列的操做都將致使表掃描，它包括數據庫函數、計算表達式等等，查詢時要儘量將操做移至等號右邊。
八、應儘可能避免在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'
九、不要在 where 子句中的「=」左邊進行函數、算術運算或其餘表達式運算，不然系統將可能沒法正確使用索引。
十、在使用索引字段做爲條件時，若是該索引是複合索引，那麼必須使用到該索引中的第一個字段做爲條件時才能保證系統使用該索引，不然該索引將不會被使用，而且應儘量的讓字段順序與索引順序相一致。
十一、不少時候用 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)
三種寫法均可以獲得一樣正確的結果，可是效率依次下降。
十二、儘可能使用表變量來代替臨時表。若是表變量包含大量數據，請注意索引很是有限（只有主鍵索引）。
1三、避免頻繁建立和刪除臨時表，以減小系統表資源的消耗。
1四、臨時表並非不可以使用，適當地使用它們可使某些例程更有效，例如，當須要重複引用大型表或經常使用表中的某個數據集時。可是，對於一次性事件，最好使用導出表。
1五、在新建臨時表時，若是一次性插入數據量很大，那麼可使用 select into 代替 create table，避免形成大量 log ，以提升速度；若是數據量不大，爲了緩和系統表的資源，應先create table，而後insert。
1六、若是使用到了臨時表，在存儲過程的最後務必將全部的臨時表顯式刪除，先 truncate table ，而後 drop table ，這樣能夠避免系統表的較長時間鎖定。
1七、在全部的存儲過程和觸發器的開始處設置 SET NOCOUNT ON ，在結束時設置 SET NOCOUNT OFF 。無需在執行存儲過程和觸發器的每一個語句後向客戶端發送 DONE_IN_PROC 消息。
1八、儘可能避免大事務操做，提升系統併發能力。
1九、儘可能避免向客戶端返回大數據量，若數據量過大，應該考慮相應需求是否合理。
20、避免使用不兼容的數據類型。例如float和int、char和varchar、binary和varbinary是不兼容的（條件判斷時）。數據類型的不兼容可能使優化器沒法執行一些原本能夠進行的優化操做。例如:
SELECT name FROM employee WHERE salary > 60000
在這條語句中,如salary字段是money型的,則優化器很難對其進行優化,由於60000是個整型數。咱們應當在編程時將整型轉化成爲錢幣型,而不要等到運行時轉化。
2一、充分利用鏈接條件（條件越多越快），在某種狀況下，兩個表之間可能不僅一個的鏈接條件，這時在 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 （group by 操做特別慢）
SELECT OrderID FROM Details WHERE UnitPrice > 10 GROUP BY OrderID
可改成：
SELECT DISTINCT OrderID FROM Details WHERE UnitPrice > 10
2四、能用UNION ALL就不要用UNION
UNION ALL不執行SELECT DISTINCT函數，這樣就會減小不少沒必要要的資源
2五、儘可能不要用SELECT INTO語句。
SELECT INOT 語句會致使表鎖定，阻止其餘用戶訪問該表。
上面咱們提到的是一些基本的提升查詢速度的注意事項,可是在更多的狀況下,每每須要反覆試驗比較不一樣的語句以獲得最佳方案。最好的方法固然是測試，看實現相同功能的SQL語句哪一個執行時間最少，可是數據庫中若是數據量不多，是比較不出來的，這時能夠用查看執行計劃，即：把實現相同功能的多條SQL語句考到查詢分析器，按CTRL+L看查所利用的索引，表掃描次數（這兩個對性能影響最大），整體上看詢成本百分比便可。
3、算法的優化
儘可能避免使用遊標，由於遊標的效率較差，若是遊標操做的數據超過1萬行，那麼就應該考慮改寫。.使用基於遊標的方法或臨時表方法以前，應先尋找基於集的解決方案來解決問題，基於集的方法一般更有效。與臨時表同樣，遊標並非不可以使用。對小型數據集使用 FAST_FORWARD 遊標一般要優於其餘逐行處理方法，尤爲是在必須引用幾個表才能得到所需的數據時。在結果集中包括「合計」的例程一般要比使用遊標執行的速度快。若是開發時間容許，基於遊標的方法和基於集的方法均可以嘗試一下，看哪種方法的效果更好。
遊標提供了對特定集合中逐行掃描的手段，通常使用遊標逐行遍歷數據，根據取出的數據不一樣條件進行不一樣的操做。尤爲對多表和大表定義的遊標（大的數據集合）循環很容易使程序進入一個漫長的等特甚至死機。
在有些場合，有時也非得使用遊標，此時也可考慮將符合條件的數據行轉入臨時表中，再對臨時表定義遊標進行操做，可時性能獲得明顯提升。
（例如：對內統計初版）
封裝存儲過程
4、創建高效的索引
建立索引通常有如下兩個目的：維護被索引列的惟一性和提供快速訪問表中數據的策略。大型數據庫有兩種索引即簇索引和非簇索引，一個沒有簇索引的表是按堆結構存儲數據，全部的數據均添加在表的尾部，而創建了簇索引的表，其數據在物理上會按照簇索引鍵的順序存儲，一個表只容許有一個簇索引，所以，根據B樹結構，能夠理解添加任何一種索引均能提升按索引列查詢的速度，但會下降插入、更新、刪除操做的性能，尤爲是當填充因子（Fill Factor）較大時。因此對索引較多的表進行頻繁的插入、更新、刪除操做，建表和索引時因設置較小的填充因子，以便在各數據頁中留下較多的自由空間，減小頁分割及從新組織的工做。
索引是從數據庫中獲取數據的最高效方式之一。95% 的數據庫性能問題均可以採用索引技術獲得解決。做爲一條規則，我一般對邏輯主鍵使用惟一的成組索引，對系統鍵（做爲存儲過程）採用惟一的非成組索引，對任何外鍵列[字段]採用非成組索引。不過，索引就象是鹽，太多了菜就鹹了。你得考慮數據庫的空間有多大，表如何進行訪問，還有這些訪問是否主要用做讀寫。
實際上，您能夠把索引理解爲一種特殊的目錄。微軟的SQL SERVER提供了兩種索引：彙集索引（clustered index，也稱聚類索引、簇集索引）和非彙集索引（nonclustered index，也稱非聚類索引、非簇集索引）。下面，咱們舉例來講明一下彙集索引和非彙集索引的區別：
其實，咱們的漢語字典的正文自己就是一個彙集索引。好比，咱們要查「安」字，就會很天然地翻開字典的前幾頁，由於「安」的拼音是「an」，而按照拼音排序漢字的字典是以英文字母「a」開頭並以「z」結尾的，那麼「安」字就天然地排在字典的前部。若是您翻完了全部以「a」開頭的部分仍然找不到這個字，那麼就說明您的字典中沒有這個字；一樣的，若是查「張」字，那您也會將您的字典翻到最後部分，由於「張」的拼音是「zhang」。也就是說，字典的正文部分自己就是一個目錄，您不須要再去查其餘目錄來找到您須要找的內容。
咱們把這種正文內容自己就是一種按照必定規則排列的目錄稱爲「彙集索引」。
若是您認識某個字，您能夠快速地從自動中查到這個字。但您也可能會遇到您不認識的字，不知道它的發音，這時候，您就不能按照剛纔的方法找到您要查的字，而須要去根據「偏旁部首」查到您要找的字，而後根據這個字後的頁碼直接翻到某頁來找到您要找的字。但您結合「部首目錄」和「檢字表」而查到的字的排序並非真正的正文的排序方法，好比您查「張」字，咱們能夠看到在查部首以後的檢字表中「張」的頁碼是672頁，檢字表中「張」的上面是「馳」字，但頁碼倒是63頁，「張」的下面是「弩」字，頁面是390頁。很顯然，這些字並非真正的分別位於「張」字的上下方，如今您看到的連續的「馳、張、弩」三字實際上就是他們在非彙集索引中的排序，是字典正文中的字在非彙集索引中的映射。咱們能夠經過這種方式來找到您所須要的字，但它須要兩個過程，先找到目錄中的結果，而後再翻到您所須要的頁碼。
咱們把這種目錄純粹是目錄，正文純粹是正文的排序方式稱爲「非彙集索引」。
進一步引伸一下，咱們能夠很容易的理解：每一個表只能有一個彙集索引，由於目錄只能按照一種方法進行排序。
（一）什麼時候使用匯集索引或非彙集索引
下面的表總結了什麼時候使用匯集索引或非彙集索引（很重要）。
事實上，咱們能夠經過前面彙集索引和非彙集索引的定義的例子來理解上表。如：返回某範圍內的數據一項。好比您的某個表有一個時間列，剛好您把聚合索引創建在了該列，這時您查詢2004年1月1日至2004年10月1日之間的所有數據時，這個速度就將是很快的，由於您的這本字典正文是按日期進行排序的，聚類索引只須要找到要檢索的全部數據中的開頭和結尾數據便可；而不像非彙集索引，必須先查到目錄中查到每一項數據對應的頁碼，而後再根據頁碼查到具體內容。
（二）結合實際，談索引使用的誤區
理論的目的是應用。雖然咱們剛纔列出了什麼時候應使用匯集索引或非彙集索引，但在實踐中以上規則卻很容易被忽視或不能根據實際狀況進行綜合分析。下面咱們將根據在實踐中遇到的實際問題來談一下索引使用的誤區，以便於你們掌握索引創建的方法。
一、主鍵就是彙集索引
這種想法筆者認爲是極端錯誤的，是對彙集索引的一種浪費。雖然SQL SERVER默認是在主鍵上創建彙集索引的。
一般，咱們會在每一個表中都創建一個ID列，以區分每條數據，而且這個ID列是自動增大的，步長通常爲1。咱們的這個辦公自動化的實例中的列Gid就是如此。此時，若是咱們將這個列設爲主鍵，SQL SERVER會將此列默認爲彙集索引。這樣作有好處，就是可讓您的數據在數據庫中按照ID進行物理排序，但筆者認爲這樣作意義不大。
顯而易見，彙集索引的優點是很明顯的，而每一個表中只能有一個彙集索引的規則，這使得彙集索引變得更加珍貴。
從咱們前面談到的彙集索引的定義咱們能夠看出，使用匯集索引的最大好處就是可以根據查詢要求，迅速縮小查詢範圍，避免全表掃描。在實際應用中，由於ID號是自動生成的，咱們並不知道每條記錄的ID號，因此咱們很難在實踐中用ID號來進行查詢。這就使讓ID號這個主鍵做爲彙集索引成爲一種資源浪費。其次，讓每一個ID號都不一樣的字段做爲彙集索引也不符合「大數目的不一樣值狀況下不該創建聚合索引」規則；固然，這種狀況只是針對用戶常常修改記錄內容，特別是索引項的時候會負做用，但對於查詢速度並無影響。
在辦公自動化系統中，不管是系統首頁顯示的須要用戶簽收的文件、會議仍是用戶進行文件查詢等任何狀況下進行數據查詢都離不開字段的是「日期」還有用戶自己的「用戶名」。
一般，辦公自動化的首頁會顯示每一個用戶還沒有簽收的文件或會議。雖然咱們的where語句能夠僅僅限制當前用戶還沒有簽收的狀況，但若是您的系統已創建了很長時間，而且數據量很大，那麼，每次每一個用戶打開首頁的時候都進行一次全表掃描，這樣作意義是不大的，絕大多數的用戶1個月前的文件都已經瀏覽過了，這樣作只能徒增數據庫的開銷而已。事實上，咱們徹底可讓用戶打開系統首頁時，數據庫僅僅查詢這個用戶近3個月來未閱覽的文件，經過「日期」這個字段來限制表掃描，提升查詢速度。若是您的辦公自動化系統已經創建的2年，那麼您的首頁顯示速度理論上將是原來速度8倍，甚至更快。
二、只要創建索引就能顯著提升查詢速度
事實上，咱們能夠發現上面的例子中，第二、3條語句徹底相同，且創建索引的字段也相同；不一樣的僅是前者在fariqi字段上創建的是非聚合索引，後者在此字段上創建的是聚合索引，但查詢速度卻有着天壤之別。因此，並不是是在任何字段上簡單地創建索引就能提升查詢速度。
從建表的語句中，咱們能夠看到這個有着1000萬數據的表中fariqi字段有5003個不一樣記錄。在此字段上創建聚合索引是再合適不過了。在現實中，咱們天天都會發幾個文件，這幾個文件的發文日期就相同，這徹底符合創建彙集索引要求的：「既不能絕大多數都相同，又不能只有極少數相同」的規則。由此看來，咱們創建「適當」的聚合索引對於咱們提升查詢速度是很是重要的。
三、把全部須要提升查詢速度的字段都加進彙集索引，以提升查詢速度
上面已經談到：在進行數據查詢時都離不開字段的是「日期」還有用戶自己的「用戶名」。既然這兩個字段都是如此的重要，咱們能夠把他們合併起來，創建一個複合索引（compound index）。
不少人認爲只要把任何字段加進彙集索引，就能提升查詢速度，也有人感到迷惑：若是把複合的彙集索引字段分開查詢，那麼查詢速度會減慢嗎？帶着這個問題，咱們來看一下如下的查詢速度（結果集都是25萬條數據）：（日期列fariqi首先排在複合彙集索引的起始列，用戶名neibuyonghu排在後列）
咱們能夠看到若是僅用匯集索引的起始列做爲查詢條件和同時用到複合彙集索引的所有列的查詢速度是幾乎同樣的，甚至比用上所有的複合索引列還要略快（在查詢結果集數目同樣的狀況下）；而若是僅用複合彙集索引的非起始列做爲查詢條件的話，這個索引是不起任何做用的。固然，語句一、2的查詢速度同樣是由於查詢的條目數同樣，若是複合索引的全部列都用上，並且查詢結果少的話，這樣就會造成「索引覆蓋」，於是性能能夠達到最優。同時，請記住：不管您是否常用聚合索引的其餘列，但其前導列必定要是使用最頻繁的列。
（三）其餘注意事項
「水可載舟，亦可覆舟」，索引也同樣。索引有助於提升檢索性能，但過多或不當的索引也會致使系統低效。由於用戶在表中每加進一個索引，數據庫就要作更多的工做。過多的索引甚至會致使索引碎片。
因此說，咱們要創建一個「適當」的索引體系，特別是對聚合索引的建立，更應精益求精，以使您的數據庫能獲得高性能的發揮
【推薦閱讀】