sqlserver之SQL語句優化

**1、查詢的邏輯執行順序 **

(1) FROM left_table
(3) join_type JOIN right_table (2) ON join_condition
(4) WHERE where_condition
(5) GROUP BY group_by_list
(6) WITH {cube | rollup}
(7) HAVING having_condition
(8) SELECT (9) DISTINCT (11) top_specification select_list
(10) ORDER BY order_by_list

標準的 SQL 的解析順序爲:

(1) FROM 子句 組裝來自不一樣數據源的數據

(2) WHERE 子句 基於指定的條件對記錄進行篩選

(3) GROUP BY 子句 將數據劃分爲多個分組

(4) 使用聚合函數進行計算

(5) 使用HAVING子句篩選分組

(6) 計算全部的表達式

(7) 使用ORDER BY對結果集進行排序

2、執行順序

1. FROM：對FROM子句中前兩個錶鏈接（鏈接條件可儘可能避免笛卡爾積）生成虛擬表vt1。 其中表鏈接有如下三種算法：

a. Loop join（嵌套循環，也叫nested loops）， 即首先遍歷 A，將A表中的每一條記錄與 B表進行鏈接比較，若是知足A.di=B.id，則返回記錄；

b. Merge join（合併鏈接）， 即首先對A,B表進行排序，而後同時遍歷A和B表，進行A.id=B.id的驗證，直到遍歷到A和B表結束；

c. Hash join（哈希鏈接）， 即首先對A表全部記錄的id進行hash計算，最終造成一個hash表，而後join時，遍歷B表，對B表每條記錄的id進行hash運算，而後在A的Hash表中驗證是否一致，最後得出結果。

2. ON: 對vt1表應用ON篩選器只有知足 join_condition 爲真的行才被插入vt2

3. OUTER(join)：若是指定了 OUTER JOIN保留表(preserved table)中未找到的行將行做爲外部行添加到vt2，生成vt3，若是from包含兩個以上表，則對上一個聯結生成的結果表和下一個表重複執行步驟1和步驟2直到結束。

4. WHERE：對vt3應用 WHERE 篩選器只有使 where_condition 爲true的行才被插入vt4

5. GROUP BY：按GROUP BY子句中的列列表對vt4中的行分組生成vt5

6. CUBE|ROLLUP：把超組(supergroups)插入vt6，生成vt6

7. HAVING：對vt6應用HAVING篩選器只有使 having_condition 爲true的組才插入vt7

8. SELECT：處理select列表產生vt8

9. DISTINCT：將重複的行從vt8中去除產生vt9

10. ORDER BY：將vt9的行按order by子句中的列列表排序生成一個遊標vc10

11. TOP：從vc10的開始處選擇指定數量或比例的行生成vt11 並返回調用者

瞭解SQL Server執行順序養成平常SQL的好習慣，也就是在實現功能時考慮性能的思想，數據庫是能進行集合運算的工具，咱們應該儘可能的利用這個工具，所謂集合運算實際就是批量運算，就是儘可能減小在客戶端進行大數據量的循環操做，而用SQL語句或者存儲過程代替。

3、只返回須要的數據

返回數據到客戶端至少須要數據庫提取數據、網絡傳輸數據、客戶端接收數據以及客戶端處理數據等環節，若是返回不須要的數據，就會增長服務器、網絡和客戶端的無效勞動，其害處是顯而易見的，避免這類事件須要注意：

A、橫向來看

(1) 不要寫SELECT * 的語句，而是選擇你須要的字段。

(2) 當在SQL語句中鏈接多個表時, 請使用表的別名並把別名前綴於每一個Column上。這樣一來,就能夠減小解析的時間並減小那些由Column歧義引發的語法錯誤。

若有表table1(ID,col1)和table2(ID,col2)
Select A.ID, A.col1, B.col2
-- Select A.ID, col1, col2    -----不要這麼寫，不利於未來程序擴展
from table1 A inner join table2 B on A.ID=B.ID Where …

B、縱向來看

(1) 合理寫WHERE子句，不要寫沒有WHERE的SQL語句。

(2) SELECT TOP N * — 沒有WHERE條件的用此替代。

4、儘可能少作重複的工做

A、控制同一語句的屢次執行，特別是一些基礎數據的屢次執行是不少程序員不多注意的。

B、減小屢次的數據轉換，也許須要數據轉換是設計的問題，可是減小次數是程序員能夠作到的。

C、杜毫不必要的子查詢和鏈接表，子查詢在執行計劃通常解釋成外鏈接，多餘的鏈接錶帶來額外的開銷。

D、合併對同一表同一條件的屢次UPDATE，好比

UPDATE EMPLOYEE SET FNAME='HAIWER'
WHERE EMP_ID=' VPA30890F'
UPDATE EMPLOYEE SET LNAME='YANG'
WHERE EMP_ID=' VPA30890F'

這兩個語句應該合併成如下一個語句

UPDATE EMPLOYEE SET FNAME='HAIWER',LNAME='YANG'WHERE EMP_ID=' VPA30890F'

E、UPDATE操做不要拆成DELETE操做+INSERT操做的形式，雖然功能相同，可是性能差異是很大的。

5、注意臨時表和表變量的用

在複雜系統中，臨時表和表變量很難避免，關於臨時表和表變量的用法，須要注意：

A、若是語句很複雜，鏈接太多，能夠考慮用臨時表和表變量分步完成。

B、若是須要屢次用到一個大表的同一部分數據，考慮用臨時表和表變量暫存這部分數據。

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

D、其餘狀況下，應該控制臨時表和表變量的使用。

E、關於臨時表和表變量的選擇，不少說法是表變量在內存，速度快，應該首選表變量，可是在實際使用中發現：

(1) 主要考慮須要放在臨時表的數據量，在數據量較多的狀況下，臨時表的速度反而更快。

(2) 執行時間段與預計執行時間(多長)

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。

6、子查詢的用法

子查詢是一個 SELECT 查詢，它嵌套在 SELECT、INSERT、UPDATE、DELETE 語句或其它子查詢中。

任何容許使用表達式的地方均可以使用子查詢，子查詢可使咱們的編程靈活多樣，能夠用來實現一些特殊的功能。可是在性能上，每每一個不合適的子查詢用法會造成一個性能瓶頸。若是子查詢的條件中使用了其外層的表的字段，這種子查詢就叫做相關子查詢。

相關子查詢能夠用IN、NOT IN、EXISTS、NOT EXISTS引入。 關於相關子查詢，應該注意：

(1) NOT IN、NOT EXISTS的相關子查詢能夠改用LEFT JOIN代替寫法。好比：

SELECT PUB_NAME FROM PUBLISHERS WHERE PUB_ID NOT IN  (SELECT PUB_ID FROM TITLES WHERE TYPE ='BUSINESS')
能夠改寫成
SELECT A.PUB_NAME FROM PUBLISHERS  A  LEFT JOIN TITLES B ON B.TYPE='BUSINESS'  AND A.PUB_ID=B. PUB_ID WHERE B.PUB_ID IS NULL

好比NOT EXISTS：

SELECT TITLE FROM TITLES WHERE NOT EXISTS
(SELECT TITLE_ID FROM SALES WHERE TITLE_ID = TITLES.TITLE_ID)
能夠改寫爲
SELECT TITLE FROM TITLES t LEFT JOIN sales s ON  t.TITLE_ID = s.TITLE_ID  WHERE s.TITLE_ID =NULL

2）若是保證子查詢沒有重複 ，IN、EXISTS的相關子查詢能夠用INNER JOIN 代替。好比：

SELECT PUB_NAME
FROM PUBLISHERS
WHERE PUB_ID IN
(SELECT PUB_ID
FROM TITLES
WHERE TYPE ='BUSINESS')
能夠改寫爲
SELECT pub_name FROM publishers p INNER JOIN titles t ON p.pub_id=t.pub_id AND t.type='BUSINESS'

(3) IN的相關子查詢用EXISTS代替，好比：

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

能夠改寫爲

select pub_name from publishers exists (select 1 from titles where type='BUSINESS' AND pub_id=publishers.pub_id )

4） 不要用COUNT(*)的子查詢判斷是否存在記錄，最好用LEFT JOIN或者EXISTS，好比有人寫這樣的語句：

SELECT JOB_DESC FROM JOBS
WHERE (SELECT COUNT(*) FROM EMPLOYEE WHERE JOB_ID=JOBS.JOB_ID)=0
能夠改寫爲
SELECT job_desc FROM jobs  j  LEFT JOIN ON employee e ON j.JOB_ID=e.JOB_ID WHERE 
e.JOB_ID=NULL
或者
SELECT  job_desc FROM jobs NOT EXISTS (SELECT 1 FROM employee WHERE job_id=jobs.job_id)

七：儘可能使用索引

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

（1）不要對索引字段進行運算，而要想辦法作變換，好比：

SELECT ID FROM T WHERE NUM/2=100    改成   select id from t where num=100/2;

（3）不要對索引字段進行格式轉換

（4）不要對索引字段使用函數

（5）不要對索引字段進行多字段鏈接

八：多表鏈接的鏈接條件對索引的選擇有着重要的意義，因此咱們在寫鏈接條件條件的時候須要特別注意

A、多表鏈接的時候，鏈接條件必須寫全，寧肯重複，不要缺漏。

B、鏈接條件儘可能使用匯集索引

C、注意ON、WHERE和HAVING部分條件的區別

ON是最早執行， WHERE次之，HAVING最後，由於ON是先把不符合條件的記錄過濾後才進行統計，它就能夠減小中間運算要處理的數據，按理說應該速度是最快的，WHERE也應該比HAVING快點的，由於它過濾數據後才進行SUM，在兩個表聯接時才用ON的，因此在一個表的時候，就剩下WHERE跟HAVING比較了。

(1) INNER JOIN

(2) LEFT JOIN (注：RIGHT JOIN 用 LEFT JOIN 替代)

(3) CROSS JOIN

其它注意和了解的地方有：

A、在IN後面值的列表中，將出現最頻繁的值放在最前面，出現得最少的放在最後面，減小判斷的次數。

B、注意UNION和UNION ALL的區別。– 容許重複數據用UNION ALL好

C、注意使用DISTINCT，在沒有必要時不要用。

D、TRUNCATE TABLE 與 DELETE 區別。

E、減小訪問數據庫的次數。

還有就是咱們寫存儲過程，若是比較長的話，最後用標記符標開，由於這樣可讀性很好，即便語句寫的不怎麼樣，可是語句工整，C# 有region，SQL我比較喜歡用的就是：

–startof 查詢在職人數

SQL語句

–end of

正式機器上咱們通常不能隨便調試程序，可是不少時候程序在咱們本機上沒問題，可是進正式系統就有問題，可是咱們又不能隨便在正式機器上操做，那麼怎麼辦呢？咱們能夠用回滾來調試咱們的存儲過程或者是SQL語句，從而排錯。

BEGIN TRAN

UPDATE a SET 字段=」

ROLLBACK

做業存儲過程我通常會加上下面這段，這樣檢查錯誤能夠放在存儲過程，若是執行錯誤回滾操做，可是若是程序裏面已經有了事務回滾，那麼存儲過程就不要寫事務了，這樣會致使事務回滾嵌套下降執行效率，可是咱們不少時候能夠把檢查放在存儲過程裏，這樣有利於咱們解讀這個存儲過程，和排錯。

BEGIN TRANSACTION

–事務回滾開始

–檢查報錯

MySQL

IF ( @@ERROR0 ) BEGIN --回滾操做 ROLLBACKTRANSACTION RAISERROR('刪除工做報告錯誤', 16, 3) RETURN END IF ( @@ERROR0 ) BEGIN --回滾操做 ROLLBACKTRANSACTION RAISERROR('刪除工做報告錯誤', 16, 3) RETURN END –結束事務

COMMIT TRANSACTION