在龐大的業(yè)務系統(tǒng)背后,一定有數(shù)據(jù)庫管理系統(tǒng)的支持。在現(xiàn)代以數(shù)據(jù)為中心的開發(fā)時代,SQL編程也顯得尤為重要。下面總結下我最近SQL編程的一些經(jīng)驗:
1.SELECT查詢要列出所有要查詢的字段
2.注意UNION和UNION ALL的區(qū)別,在IN,OR,UNION ALL這三種方案中,UNION ALL的執(zhí)行效率是最高的。
3.視圖定義要盡量簡單,最好不要包含業(yè)務邏輯。比如:在業(yè)務系統(tǒng)中,單據(jù)會有多種狀態(tài),那么在系統(tǒng)與系統(tǒng)交互的過程中,可能兩邊的狀態(tài)碼定義的不同,那么就需要映射。在這種場景下,強烈建議這種映射不要放在視圖定義或SQL查詢中,因為這會降低查詢的性能。
4.表變量與臨時表的選擇。表變量會將數(shù)據(jù)存儲在數(shù)據(jù)庫服務的內存中,臨時表會將數(shù)據(jù)存儲在數(shù)據(jù)庫服務器的磁盤上,會產(chǎn)生I/O,因此臨時表消耗資料要多些,性能顯示要差些。一般來說,建議采用表變量。如果數(shù)據(jù)量大(選取的字段多,有大字段,數(shù)據(jù)條目超過10W),又要連續(xù)使用多次的,建議用臨時表。
5.在表變量上設計主鍵是有百益而無一害的,臨時表上更應該設計主鍵了。設計主鍵主要是讓數(shù)據(jù)有序存儲,提高查詢性能。
6.要把握INNER JOIN和LEFT/RIGHT JOIN的區(qū)別。選擇好了可以使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),這樣會嚴重影響性能。解決方案是,一在設計階段注意規(guī)范,二是可以臨時在JOIN … ON子句中做顯式類型轉換。另外,WHERE是篩選子句,JOIN … ON是連接語句,把篩選子句寫在JOIN … ON上與寫在WHERE后面沒有區(qū)別,但是感覺兩者職責不分,代碼不夠幽雅。
??? 先寫到這里,以后有更多經(jīng)驗,心得再來更新。如果你有更多經(jīng)驗,不妨民分享于我。謝謝。
更多文章、技術交流、商務合作、聯(lián)系博主
微信掃碼或搜索:z360901061

微信掃一掃加我為好友
QQ號聯(lián)系: 360901061
您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對您有幫助就好】元
