在龐大的業務系統背后，一定有數據庫管理系統的支持。在現代以數據為中心的開發時代，SQL編程也顯得尤為重要。下面總結下我最近SQL編程的一些經驗：

1.SELECT查詢要列出所有要查詢的字段

2.注意UNION和UNION ALL的區別,在IN，OR，UNION ALL這三種方案中，UNION ALL的執行效率是最高的。

3.視圖定義要盡量簡單，最好不要包含業務邏輯。比如：在業務系統中，單據會有多種狀態，那么在系統與系統交互的過程中，可能兩邊的狀態碼定義的不同，那么就需要映射。在這種場景下，強烈建議這種映射不要放在視圖定義或SQL查詢中，因為這會降低查詢的性能。

4.表變量與臨時表的選擇。表變量會將數據存儲在數據庫服務的內存中，臨時表會將數據存儲在數據庫服務器的磁盤上，會產生I/O，因此臨時表消耗資料要多些，性能顯示要差些。一般來說，建議采用表變量。如果數據量大（選取的字段多，有大字段，數據條目超過10W），又要連續使用多次的，建議用臨時表。

5.在表變量上設計主鍵是有百益而無一害的，臨時表上更應該設計主鍵了。設計主鍵主要是讓數據有序存儲，提高查詢性能。

6.要把握INNER JOIN和LEFT/RIGHT JOIN的區別。選擇好了可以使SQL很簡潔高效。

7.EXISTS的效率比IN要好十倍的樣子。下面三個版本的效果，V1<V2<V3。

sql

      --V1

DELETE FROM dbo.Master

WHERE TransactionNumber IN

(

SELECT OriginalTransactionNumber FROM dbo.MasterHistory WITH(NOLOCK)

)



--V2

DELETE FROM dbo.Master

WHERE EXISTS

(

SELECT 1 FROM dbo.MasterHistory b WITH(NOLOCK)

WHERE b.OriginalTransactionNumber=TransactionNumber

)



--V3

DELETE a

FROM dbo.Master a

INNER JOIN dbo.MasterHistory b WITH(NOLOCK)

ON a.TransactionNumber=b.OriginalTransactionNumber


    

8.WHERE篩選子句要以選擇性高的放在前面，選擇性低或沒有選擇性的放在后面。JOIN … ON中的連接條件中要避免左右兩邊字段的類型轉換，比如a.ItemNumber是NCHAR(25),而b.ItemNumber是VARCHAR(25),這樣會嚴重影響性能。解決方案是，一在設計階段注意規范，二是可以臨時在JOIN … ON子句中做顯式類型轉換。另外，WHERE是篩選子句，JOIN … ON是連接語句，把篩選子句寫在JOIN … ON上與寫在WHERE后面沒有區別，但是感覺兩者職責不分，代碼不夠幽雅。

??? 先寫到這里，以后有更多經驗，心得再來更新。如果你有更多經驗，不妨民分享于我。謝謝。

T-SQL經驗總結