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

1、?
數據庫邏輯設計的規范化
數據庫邏輯設計的規范化就是我們一般所說的范式，我們可以這樣來簡單理解范式：
第1規范：表的列具有原子性，不可再分割，即列的信息，不能分割。只要是關系型數據庫都自動滿足。

第2規范:?要有主鍵。為實現區分通常需要為表加上一個列，以存儲各個實例的唯一標識。

第3規范:?

表中不要有冗余數據，就是說如果表中的數據可以推導出來，就不應該設置該字段

2、?

合理的冗余
完全按照規范化設計的系統幾乎是不可能的，除非系統特別的小，在規范化設計后，有計劃地加入冗余是必要的。
冗余可以是冗余數據庫、冗余表或者冗余字段，不同粒度的冗余可以起到不同的作用。
冗余可以是為了編程方便而增加，也可以是為了性能的提高而增加。從性能角度來說，冗余數據庫可以分散數據庫壓力，冗余表可以分散數據量大的表的并發壓力，也可以加快特殊查詢的速度，冗余字段可以有效減少數據庫表的連接，提高效率。

3、?
字段的設計
字段是數據庫最基本的單位，其設計對性能的影響是很大的。需要注意如下：
A、數據類型盡量用數字型，數字型的比較比字符型的快很多。
B、數據類型盡量小，這里的盡量小是指在滿足可以預見的未來需求的前提下的。

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

4、?

使用存儲過程 [模塊化編程，可以提高速度]

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

A、?
根據數據量決定哪些表需要增加索引，數據量小的可以只有主鍵。

B、?
根據使用頻率決定哪些字段需要建立索引，選擇經常作為連接條件、篩選條件、聚合查詢、排序的字段作為索引的候選字段。

C、把經常一起出現的字段組合在一起，組成組合索引，組合索引的字段順序與主鍵一樣，也需要把最常用的字段放在前面，把重復率低的字段放在前面。
D、唯一性太差的不適合單獨創建索引，比如性別

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

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

G、?什么創建索引后，速度就會變快?

原理示意圖:

6.使用索引的注意事項 A、對于創建的多列索引，只要查詢條件使用了最左邊的列，索引一般就會被使用。
B、對于使用like的查詢，查詢如果是 ?‘%aaa’ 不會使用到索引，‘aaa%’ 會使用到索引。
C、如果條件中有or，即使其中有條件帶索引也不會使用。換言之，就是要求使用的所有字段，都必須建立索引, 我們建議大家盡量避免使用or 關鍵字
7、水平分割 就是將數據分布在不同的相同字段的表中，比如qq登陸表 我們可以指定一個規則分布存儲在不同的表中，例如根據qq號%3=（0-2之間的數字），創建三張表分別為user0，user1，user2 8、垂直分割

一句話: 如果一張表某個字段，信息量大，但是我們很少查詢，則可以考慮把這些字段，單獨的放入到一張表中，這種方式稱為垂直分割.

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

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

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

D、對于聚合查詢，可以用HAVING子句進一步限定返回的行。

2、?
注意事務和鎖
事務是數據庫應用中和重要的工具，它有原子性、一致性、隔離性、持久性這四個屬性，很多操作我們都需要利用事務來保證數據的正確性。

?在使用事務中我們需要做到盡量避免死鎖、盡量減少阻塞。具體以下方面需要特別注意：

A、事務操作過程要盡量小，能拆分的事務要拆分開來。

B、?

事務操作過程不應該有交互，因為交互等待的時候，事務并未結束，可能鎖定了很多資源。

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

D、提高事務中每個語句的效率，利用索引和其他方法提高每個語句的效率可以有效地減少整個事務的執行時間。

E、 盡量不要指定鎖類型和索引，SQL SERVER允許我們自己指定語句使用的鎖類型和索引，但是一般情況下，SQL?
SERVER優化器選擇的鎖類型和索引是在當前數據量和查詢條件下是最優的，我們指定的可能只是在目前情況下更有，但是數據量和數據分布在將來是會變化的。

F、 查詢時可以用較低的隔離級別，特別是報表查詢的時候，可以選擇最低的隔離級別（未提交讀）。
3、?
注意臨時表和表變量的用法
在復雜系統中，臨時表和表變量很難避免，關于臨時表和表變量的用法，需要注意：

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來避免上述問題。
4、?
子查詢的用法
子查詢是一個 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（小表），看下面的查詢：
1、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的索引
結果：第一句效率高。
2、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的索引
結果：第二句效率高。

?

6、?
盡量使用索引
建立索引后，并不是每個查詢都會使用索引，在使用索引的情況下，索引的使用效率也會有很大的差別。只要我們在查詢語句中沒有強制指定索引，索引的選擇和使用方法是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?
子句中使用!=或<>操作符，否則將引擎放棄使用索引而進行全表掃描。

7、?
其他需要注意的地方
經驗表明，問題發現的越早解決的成本越低，很多性能問題可以在編碼階段就發現，為了提早發現性能問題，需要注意：
A、程序員注意、關心各表的數據量。
B、?
編碼過程和單元測試過程盡量用數據量較大的數據庫測試，最好能用實際數據測試。
C、?
每個SQL語句盡量簡單
D、?
注意數據庫函數的限制以及其性能
8、學會分辯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參數
四、測試、試運行、維護階段
測試的主要任務是發現并修改系統的問題，其中性能問題也是一個重要的方面。重點應該放在發現有性能問題的地方，并進行必要的優化。主要進行語句優化、索引優化等。
試運行和維護階段是在實際的環境下運行系統，發現的問題范圍更廣，可能涉及操作系統、網絡以及多用戶并發環境出現的問題，其優化也擴展到操作系統、網絡以及數據庫物理存儲的優化。
這個階段的優花方法在這里不再展開，只說明下索引維護的方法：
A、
可以用DBCC DBREINDEX語句或者SQL SERVER維護計劃設定定時進行索引重建，索引重建的目的是提高索引的效能。
B、
可以用語句UPDATE STATISTICS或者SQL SERVER維護計劃設定定時進行索引統計信息的更新，其目的是使得統計信息更能反映實際情況，從而使得優化器選擇更合適的索引。
C、
可以用DBCC CHECKDB或者DBCC CHECKTABLE語句檢查數據庫表和索引是否有問題，這兩個語句也能修復一般的問題。

三、?
網上資料中一些說法的個人理解
1、 “應盡量避免在 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是不同概念的，以上說法的兩個查詢的意義和記錄數是不同的。
2、 “應盡量避免在 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”
個人意見：主要對全表掃描的說法不贊同。
3、 “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”
個人意見：主要對全表掃描的說法不贊同。
4、?
“盡可能的使用 VARCHAR/NVARCHAR 代替 CHAR/NCHAR?
，因為首先變長字段存儲空間小，可以節省存儲空間，其次對于查詢來說，在一個相對較小的字段內搜索效率顯然要高些。”
個人意見：“在一個相對較小的字段內搜索效率顯然要高些”顯然是對的，但是字段的長短似乎不是由變不變長決定，而是業務本身決定。在SQLSERVER6.5或者之前版本，不定長字符串字段的比較速度比定長的字符串字段的比較速度慢很多，所以對于那些版本，我們都是推薦使用定長字段存儲一些關鍵字段。而在2000版本，修改了不定長字符串字段的比較方法，與定長字段的比較速度差別不大了，這樣為了方便，我們大量使用不定長字段。

轉載于:https://www.cnblogs.com/yxlblogs/p/3415634.html

總結

以上是生活随笔為你收集整理的总结sqlserver数据库性能优化相关的注意事项的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。