總結sqlserver數據庫性能優化相關的注意事項

1、分析階段
通常來講，在系統分析階段每每有太多須要關注的地方，系統各類功能性、可用性、可靠性、安全性需求每每吸引了咱們大部分的注意力，可是，咱們必須注意，性能是很重要的非功能性需求，必須根據系統的特色肯定其實時性需求、響應時間的需求、硬件的配置等。最好能有各類需求的量化的指標。
另外一方面，在分析階段應該根據各類需求區分出系統的類型，大的方面，區分是OLTP（聯機事務處理系統）和OLAP（聯機分析處理系統）。
2、設計階段
設計階段能夠說是之後系統性能的關鍵階段，在這個階段，有一個關係到之後幾乎全部性能調優的過程—數據庫設計。
在數據庫設計完成後，能夠進行初步的索引設計，好的索引設計能夠指導編碼階段寫出高效率的代碼，爲整個系統的性能打下良好的基礎。
如下是性能要求設計階段須要注意的：

一、 
數據庫邏輯設計的規範化
數據庫邏輯設計的規範化就是咱們通常所說的範式，咱們能夠這樣來簡單理解範式：
第1規範：表的列具備原子性，不可再分割，即列的信息，不能分割。只要是關係型數據庫都自動知足。

第2規範: 要有主鍵。爲實現區分一般須要爲表加上一個列，以存儲各個實例的惟一標識。

第3規範: 

表中不要有冗餘數據，就是說若是表中的數據能夠推導出來，就不該該設置該字段

二、 

合理的冗餘
徹底按照規範化設計的系統幾乎是不可能的，除非系統特別的小，在規範化設計後，有計劃地加入冗餘是必要的。
冗餘能夠是冗餘數據庫、冗餘表或者冗餘字段，不一樣粒度的冗餘能夠起到不一樣的做用。
冗餘能夠是爲了編程方便而增長，也能夠是爲了性能的提升而增長。從性能角度來講，冗餘數據庫能夠分散數據庫壓力，冗餘表能夠分散數據量大的表的併發壓力，也能夠加快特殊查詢的速度，冗餘字段能夠有效減小數據庫表的鏈接，提升效率。

三、 
字段的設計
字段是數據庫最基本的單位，其設計對性能的影響是很大的。須要注意以下：
A、數據類型儘可能用數字型，數字型的比較比字符型的快不少。
B、數據類型儘可能小，這裏的儘可能小是指在知足能夠預見的將來需求的前提下的。

C、自增字段要慎用，不利於數據遷移。

四、 

使用存儲過程 [模塊化編程，能夠提升速度]

五、 
索引的設計
在設計階段，能夠根據功能和性能的需求進行初步的索引設計，這裏須要根據預計的數據量和查詢來設計索引，可能與未來實際使用的時候會有所區別。
關於索引的選擇，應改主意：

A、 
根據數據量決定哪些表須要增長索引，數據量小的能夠只有主鍵。

B、 
根據使用頻率決定哪些字段須要創建索引，選擇常常做爲鏈接條件、篩選條件、聚合查詢、排序的字段做爲索引的候選字段。

C、把常常一塊兒出現的字段組合在一塊兒，組成組合索引，組合索引的字段順序與主鍵同樣，也須要把最經常使用的字段放在前面，把重複率低的字段放在前面。
D、惟一性太差的不適合單首創建索引，好比性別

E、更新頻繁的字段不適合建立索引

F、 一個表不要加太多索引，由於索引影響插入和更新的速度。

G、  什麼建立索引後，速度就會變快?

原理示意圖:

6.使用索引的注意事項

A、對於建立的多列索引，只要查詢條件使用了最左邊的列，索引通常就會被使用。
B、 對於使用like 的查詢，查詢若是是  ‘ %aaa ’ 不會使用到索引，‘aaa%’ 會使用到索引。
C、 若是條件中有or ，即便其中有條件帶索引也不會使用。換言之，就是要求使用的全部字段，都必須創建索引, 咱們建議你們儘可能避免使用 or 關鍵字
七、水平分割

就是將數據分佈在不一樣的相同字段的表中，好比qq登錄表

咱們能夠指定一個規則分佈存儲在不一樣的表中，例如根據qq號%3=（0-2之間的數字），建立三張表分別爲user0，user1，user2

八、垂直分割

一句話: 若是一張表某個字段，信息量大，可是咱們不多查詢，則能夠考慮把這些字段，單獨的放入到一張表中，這種方式稱爲垂直分割.

3、編碼階段
編碼階段是本文的重點，由於在設計肯定的狀況下，編碼的質量幾乎決定了整個系統的質量。
編碼階段首先是須要全部程序員有性能意識，也就是在實現功能同時有考慮性能的思想，數據庫是能進行集合運算的工具，咱們應該儘可能的利用這個工具，所謂集合運算實際是批量運算，就是儘可能減小在客戶端進行大數據量的循環操做，而用SQL語句或者存儲過程代替。關於思想和意識，很難說得很清楚，須要在編程過程當中來體會。
下面羅列一些編程階段須要注意的事項：
一、 
只返回須要的數據
返回數據到客戶端至少須要數據庫提取數據、網絡傳輸數據、客戶端接收數據以及客戶端處理數據等環節，若是返回不須要的數據，就會增長服務器、網絡和客戶端的無效勞動，其害處是顯而易見的，避免這類事件須要注意：

A、橫向來看，不要寫SELECT *的語句，而是選擇你須要的字段。

B、 
縱向來看，合理寫WHERE子句，不要寫沒有WHERE的SQL語句。
C、注意SELECT 
INTO後的WHERE子句，由於SELECT 
INTO把數據插入到臨時表，這個過程會鎖定一些系統表，若是這個WHERE子句返回的數據過多或者速度太慢，會形成系統表長期鎖定，諸塞其餘進程。

D、對於聚合查詢，能夠用HAVING子句進一步限定返回的行。

二、 
注意事務和鎖
事務是數據庫應用中和重要的工具，它有原子性、一致性、隔離性、持久性這四個屬性，不少操做咱們都須要利用事務來保證數據的正確性。

 在使用事務中咱們須要作到儘可能避免死鎖、儘可能減小阻塞。具體如下方面須要特別注意：

A、事務操做過程要儘可能小，能拆分的事務要拆分開來。

B、 

事務操做過程不該該有交互，由於交互等待的時候，事務並未結束，可能鎖定了不少資源。

C、 事務操做過程要按同一順序訪問對象。

D、提升事務中每一個語句的效率，利用索引和其餘方法提升每一個語句的效率能夠有效地減小整個事務的執行時間。

E、 儘可能不要指定鎖類型和索引，SQL SERVER容許咱們本身指定語句使用的鎖類型和索引，可是通常狀況下，SQL 
SERVER優化器選擇的鎖類型和索引是在當前數據量和查詢條件下是最優的，咱們指定的可能只是在目前狀況下更有，可是數據量和數據分佈在未來是會變化的。

F、 查詢時能夠用較低的隔離級別，特別是報表查詢的時候，能夠選擇最低的隔離級別（未提交讀）。
三、 
注意臨時表和表變量的用法
在複雜系統中，臨時表和表變量很難避免，關於臨時表和表變量的用法，須要注意：

A、若是語句很複雜，鏈接太多，能夠考慮用臨時表和表變量分步完成。
B、若是須要屢次用到一個大表的同一部分數據，考慮用臨時表和表變量暫存這部分數據。

C、 
若是須要綜合多個表的數據，造成一個結果，能夠考慮用臨時表和表變量分步彙總這多個表的數據。

D、其餘狀況下，應該控制臨時表和表變量的使用。
E、關於臨時表和表變量的選擇，不少說法是表變量在內存，速度快，應該首選表變量，可是在實際使用中發現，這個選擇主要考慮須要放在臨時表的數據量，在數據量較多的狀況下，臨時表的速度反而更快。

F、 關於臨時表產生使用SELECT INTO和CREATE TABLE + INSERT INTO的選擇，咱們作過測試，通常狀況下，SELECT 
INTO會比CREATE TABLE + INSERT INTO的方法快不少，可是SELECT 
INTO會鎖定TEMPDB的系統表SYSOBJECTS、SYSINDEXES、SYSCOLUMNS，在多用戶併發環境下，容易阻塞其餘進程，因此個人建議是，在併發系統中，儘可能使用CREATE 
TABLE + INSERT INTO，而大數據量的單個語句使用中，使用SELECT 
INTO。
G、
注意排序規則，用CREATE 
TABLE創建的臨時表，若是不指定字段的排序規則，會選擇TEMPDB的默認排序規則，而不是當前數據庫的排序規則。若是當前數據庫的排序規則和TEMPDB的排序規則不一樣，鏈接的時候就會出現排序規則的衝突錯誤。通常能夠在CREATE 
TABLE創建臨時表時指定字段的排序規則爲DATABASE_DEFAULT來避免上述問題。
四、 
子查詢的用法
子查詢是一個 SELECT 查詢，它嵌套在 
SELECT、INSERT、UPDATE、DELETE 
語句或其它子查詢中。任何容許使用表達式的地方均可以使用子查詢。

子查詢可使咱們的編程靈活多樣，能夠用來實現一些特殊的功能。可是在性能上，每每一個不合適的子查詢用法會造成一個性能瓶頸。

若是子查詢的條件中使用了其外層的表的字段，這種子查詢就叫做相關子查詢。相關子查詢能夠用IN、NOT IN、EXISTS、NOT 
EXISTS引入。
關於相關子查詢，應該注意：
A、NOT IN、NOT EXISTS的相關子查詢能夠改用LEFT 
JOIN代替寫法。好比：
1.SELECT PUB_NAME FROM PUBLISHERS WHERE PUB_ID NOT IN (SELECT PUB_ID FROM TITLES WHERE TYPE = 'BUSINESS')

能夠改寫爲

1.SELECT A.PUB_NAME FROM PUBLISHERS A LEFT JOIN TITLES B ON A.PUB_ID=B.PUB_ID AND B.TYPE = 'BUSINESS' WHERE B.PUB_ID IS NULL

1.SELECT TITLE FROM TITLES WHERE NOT EXISTS (SELECT TITLE_ID FROM SALES WHERE TITLE_ID = TITLES.TITLE_ID)
能夠改寫成：
1.SELECT TITLE FROM TITLES LEFT JOIN SALES ON SALES.TITLE_ID = TITLES.TITLE_ID WHERE SALES.TITLE_ID IS NULL

B、 若是保證子查詢沒有重複 ，IN、EXISTS的相關子查詢能夠用INNER JOIN 

1.SELECT PUB_NAME FROM PUBLISHERS WHERE PUB_ID IN (SELECT PUB_ID FROM TITLES WHERE TYPE = 'BUSINESS')

能夠改寫爲

1.SELECT A.PUB_NAME FROM PUBLISHERS A INNER JOIN TITLES B ON A.PUB_ID=B.PUB_ID AND B.TYPE = 'BUSINESS'

1.SELECT TITLE FROM TITLES WHERE EXISTS (SELECT TITLE_ID FROM SALES WHERE TITLE_ID = TITLES.TITLE_ID)
能夠改寫成：
1.SELECT TITLE FROM TITLES INNER JOIN SALES ON SALES.TITLE_ID = TITLES.TITLE_ID

C、區別：in是關係運算符，exists是相關子查詢。
exists的效率比in高的說法不正確，要看具體狀況，儘量利用索引。若是兩個表中一個較小，一個是大表，則子查詢表大的用exists，子查詢表小的用in。

例：設有兩個表td（大表）和tx（小表），看下面的查詢：
一、select * from td where col in (select col from tx); --利用了td的索引
select * from td where exists (select col from tx where col=td.col); --利用tab2的索引
結果：第一句效率高。
二、select * from tx where col in (select col from td); --利用了tx的索引
select * from tx where exists (select col from td where col=tx.col); --利用了td的索引
結果：第二句效率高。

 

六、 
儘可能使用索引
創建索引後，並非每一個查詢都會使用索引，在使用索引的狀況下，索引的使用效率也會有很大的差異。只要咱們在查詢語句中沒有強制指定索引，索引的選擇和使用方法是SQLSERVER的優化器自動做的選擇，而它選擇的根據是查詢語句的條件以及相關表的統計信息，這就要求咱們在寫SQL語句的時候儘可能使得優化器可使用索引。
爲了使得優化器能高效使用索引，寫語句的時候應該注意：

A、不要對索引字段進行運算，而要想辦法作變換，好比
SELECT ID FROM T WHERE NUM/2=100
應改成:
SELECT ID FROM T WHERE NUM=100*2

SELECT ID FROM T WHERE NUM/2=NUM1
若是NUM有索引應改成:
SELECT ID FROM T WHERE NUM=NUM1*2
若是NUM1有索引則不該該改。
發現過這樣的語句：
1.
SELECT 年,月,金額 FROM 結餘表 WHERE 100*年+月=2007*100+10
應該改成：
SELECT 年,月,金額 FROM 結餘表 WHERE 年=2007 AND 月=10
B、
不要對索引字段進行格式轉換
日期字段的例子：
WHERE CONVERT(VARCHAR(10), 日期字段,120)=’2008-08-15’
應該改成
WHERE日期字段〉=’2008-08-15’AND日期字段<’2008-08-16’

C、 不要對索引字段使用函數
WHERE LEFT(NAME, 3)='ABC' 或者WHERE SUBSTRING(NAME,1, 3)='ABC'
應改成:
WHERE NAME LIKE 'ABC%'
日期查詢的例子：
WHERE DATEDIFF(DAY, 日期,'2005-11-30')=0 應改成:WHERE 日期 >='2005-11-30' AND 日期 <'2005-12-1'
WHERE DATEDIFF(DAY, 日期,'2005-11-30')>0 應改成:WHERE 日期 <'2005-11-30'
WHERE DATEDIFF(DAY, 日期,'2005-11-30')>=0應改成:WHERE 日期 <'2005-12-01'
WHERE DATEDIFF(DAY, 日期,'2005-11-30')<0應改成:WHERE 日期>='2005-12-01'
WHERE DATEDIFF(DAY, 日期,'2005-11-30')<=0應改成:WHERE 日期>='2005-11-30'
D、不要對索引字段進行多字段鏈接
好比：
WHERE FAME+ ’.’+LNAME=‘HAIWEI.YANG’
應改成:WHERE FNAME=‘HAIWEI’ AND LNAME=‘YANG’

E、應儘可能避免在 WHERE 
子句中使用!=或<>操做符，不然將引擎放棄使用索引而進行全表掃描。

七、 
其餘須要注意的地方
經驗代表，問題發現的越早解決的成本越低，不少性能問題能夠在編碼階段就發現，爲了提前發現性能問題，須要注意：
A、程序員注意、關心各表的數據量。
B、 
編碼過程和單元測試過程儘可能用數據量較大的數據庫測試，最好能用實際數據測試。
C、 
每一個SQL語句儘可能簡單
D、 
注意數據庫函數的限制以及其性能
八、學會分辯SQL語句的優劣
本身分辨SQL語句的優劣很是重要，只有本身能分辨優劣才能寫出高效的語句。
A、查看SQL語句的執行計劃，能夠在查詢分析其使用CTRL+L圖形化的顯示執行計劃，通常應該注意百分比最大的幾個圖形的屬性，把鼠標移動到其上面會顯示這個圖形的屬性，須要注意預計成本的數據，也要注意其標題，通常都是CLUSTERED INDEX SEEK 、

INDEX SEEK 、CLUSTERED INDEX SCAN 、INDEX SCAN 、TABLE SCAN等，其中出現SCAN說明語句有優化的餘地。也能夠用語句
SET STATISTICS IO ON --運行set statistics io命令能夠獲得SQL語句的logical reads信息

B、
用事件探查器跟蹤系統的運行，可疑跟蹤到執行的語句，以及所用的時間，CPU用量以及I/O數據，從而分析語句的效率。
C、
能夠用WINDOWS的系統性能檢測器，關注CPU、I/O參數
4、測試、試運行、維護階段
測試的主要任務是發現並修改系統的問題，其中性能問題也是一個重要的方面。重點應該放在發現有性能問題的地方，並進行必要的優化。主要進行語句優化、索引優化等。
試運行和維護階段是在實際的環境下運行系統，發現的問題範圍更廣，可能涉及操做系統、網絡以及多用戶併發環境出現的問題，其優化也擴展到操做系統、網絡以及數據庫物理存儲的優化。
這個階段的優花方法在這裏再也不展開，只說明下索引維護的方法：
A、
能夠用DBCC DBREINDEX語句或者SQL SERVER維護計劃設定定時進行索引重建，索引重建的目的是提升索引的效能。
B、
能夠用語句UPDATE STATISTICS或者SQL SERVER維護計劃設定定時進行索引統計信息的更新，其目的是使得統計信息更能反映實際狀況，從而使得優化器選擇更合適的索引。
C、
能夠用DBCC CHECKDB或者DBCC CHECKTABLE語句檢查數據庫表和索引是否有問題，這兩個語句也能修復通常的問題。

3、 
網上資料中一些說法的我的理解
一、 「應儘可能避免在 WHERE 子句中對字段進行 NULL 
值判斷，不然將致使引擎放棄使用索引而進行全表掃描，如：
SELECT ID FROM T WHERE NUM IS 
NULL
能夠在NUM上設置默認值0，確保表中NUM列沒有NULL值，而後這樣查詢：
SELECT ID FROM T WHERE 
NUM=0」
我的意見：通過測試，IS NULL也是能夠用INDEX 
SEEK查找的，0和NULL是不一樣概念的，以上說法的兩個查詢的意義和記錄數是不一樣的。
二、 「應儘可能避免在 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 也要慎用，不然會致使全表掃描，如：
SELECT ID 
FROM T WHERE NUM IN(1,2,3)
對於連續的數值，能用 BETWEEN 就不要用 IN 了：
SELECT ID FROM T 
WHERE NUM BETWEEN 1 AND 3」
我的意見：主要對全表掃描的說法不贊同。
四、 
「儘量的使用 VARCHAR/NVARCHAR 代替 CHAR/NCHAR 
，由於首先變長字段存儲空間小，能夠節省存儲空間，其次對於查詢來講，在一個相對較小的字段內搜索效率顯然要高些。」
我的意見：「在一個相對較小的字段內搜索效率顯然要高些」顯然是對的，可是字段的長短彷佛不是由變不變長決定，而是業務自己決定。在SQLSERVER6.5或者以前版本，不定長字符串字段的比較速度比定長的字符串字段的比較速度慢不少，因此對於那些版本，咱們都是推薦使用定長字段存儲一些關鍵字段。而在2000版本，修改了不定長字符串字段的比較方法，與定長字段的比較速度差異不大了，這樣爲了方便，咱們大量使用不定長字段。