小編給大家分享一下寫出高性能sql的方法，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

成都創(chuàng)新互聯(lián)公司專注于企業(yè)成都營銷網(wǎng)站建設(shè)、網(wǎng)站重做改版、寧波網(wǎng)站定制設(shè)計、自適應(yīng)品牌網(wǎng)站建設(shè)、成都h5網(wǎng)站建設(shè)、成都商城網(wǎng)站開發(fā)、集團公司官網(wǎng)建設(shè)、成都外貿(mào)網(wǎng)站建設(shè)、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁設(shè)計等建站業(yè)務(wù)，價格優(yōu)惠性價比高，為寧波等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。

首先要搞明白什么叫執(zhí)行計劃？

執(zhí)行計劃是數(shù)據(jù)庫根據(jù)SQL語句和相關(guān)表的統(tǒng)計信息作出的一個查詢方案，這個方案是由查詢優(yōu)化器自動分析產(chǎn)生的，比如一條SQL語句如果用來從一個 10萬條記錄的表中查1條記錄，那查詢優(yōu)化器會選擇“索引查找”方式，如果該表進行了歸檔，當前只剩下5000條記錄了，那查詢優(yōu)化器就會改變方案，采用 “全表掃描”方式。

可見，執(zhí)行計劃并不是固定的，它是“個性化的”。產(chǎn)生一個正確的“執(zhí)行計劃”有兩點很重要：

SQL語句是否清晰地告訴查詢優(yōu)化器它想干什么？

查詢優(yōu)化器得到的數(shù)據(jù)庫統(tǒng)計信息是否是最新的、正確的？

統(tǒng)一SQL語句的寫法

對于以下兩句SQL語句，程序員認為是相同的，數(shù)據(jù)庫查詢優(yōu)化器認為是不同的。

select*from dual 
select*From dual

其實就是大小寫不同，查詢分析器就認為是兩句不同的SQL語句，必須進行兩次解析。生成2個執(zhí)行計劃。所以作為程序員，應(yīng)該保證相同的查詢語句在任何地方都一致，多一個空格都不行！

不要把SQL語句寫得太復(fù)雜

我經(jīng)常看到，從數(shù)據(jù)庫中捕捉到的一條SQL語句打印出來有2張A4紙這么長。一般來說這么復(fù)雜的語句通常都是有問題的。我拿著這2頁長的SQL語句去請教原作者，結(jié)果他說時間太長，他一時也看不懂了?？上攵B原作者都有可能看糊涂的SQL語句，數(shù)據(jù)庫也一樣會看糊涂。

一般，將一個Select語句的結(jié)果作為子集，然后從該子集中再進行查詢，這種一層嵌套語句還是比較常見的，但是根據(jù)經(jīng)驗，超過3層嵌套，查詢優(yōu)化器就很容易給出錯誤的執(zhí)行計劃。因為它被繞暈了。像這種類似人工智能的東西，終究比人的分辨力要差些，如果人都看暈了，我可以保證數(shù)據(jù)庫也會暈的。

另外，執(zhí)行計劃是可以被重用的，越簡單的SQL語句被重用的可能性越高。而復(fù)雜的SQL語句只要有一個字符發(fā)生變化就必須重新解析，然后再把這一大堆垃圾塞在內(nèi)存里?？上攵瑪?shù)據(jù)庫的效率會何等低下。

使用“臨時表”暫存中間結(jié)果

簡化SQL語句的重要方法就是采用臨時表暫存中間結(jié)果，但是，臨時表的好處遠遠不止這些，將臨時結(jié)果暫存在臨時表，后面的查詢就在tempdb中了，這可以避免程序中多次掃描主表，也大大減少了程序執(zhí)行中“共享鎖”阻塞“更新鎖”，減少了阻塞，提高了并發(fā)性能。

OLTP系統(tǒng)SQL語句必須采用綁定變量

select*from orderheader where changetime >'2010-10-20 00:00:01' 
select*from orderheader where changetime >'2010-09-22 00:00:01'

以上兩句語句，查詢優(yōu)化器認為是不同的SQL語句，需要解析兩次。如果采用綁定變量

select*from orderheader where changetime >@chgtime

@chgtime變量可以傳入任何值，這樣大量的類似查詢可以重用該執(zhí)行計劃了，這可以大大降低數(shù)據(jù)庫解析SQL語句的負擔。一次解析，多次重用，是提高數(shù)據(jù)庫效率的原則。

綁定變量窺測

事物都存在兩面性，綁定變量對大多數(shù)OLTP處理是適用的，但是也有例外。比如在where條件中的字段是“傾斜字段”的時候。

“傾斜字段”指該列中的絕大多數(shù)的值都是相同的，比如一張人口調(diào)查表，其中“民族”這列，90%以上都是漢族。那么如果一個SQL語句要查詢30歲的漢族人口有多少，那“民族”這列必然要被放在where條件中。這個時候如果采用綁定變量@nation會存在很大問題。

試想如果@nation傳入的第一個值是“漢族”，那整個執(zhí)行計劃必然會選擇表掃描。然后，第二個值傳入的是“布依族”，按理說“布依族”占的比例可能只有萬分之一，應(yīng)該采用索引查找。但是，由于重用了第一次解析的“漢族”的那個執(zhí)行計劃，那么第二次也將采用表掃描方式。這個問題就是著名的“綁定變量窺測”，建議對于“傾斜字段”不要采用綁定變量。

只在必要的情況下才使用begin tran

SQL Server中一句SQL語句默認就是一個事務(wù)，在該語句執(zhí)行完成后也是默認commit的。其實，這就是begin tran的一個最小化的形式，好比在每句語句開頭隱含了一個begin tran，結(jié)束時隱含了一個commit。

有些情況下，我們需要顯式聲明begin tran，比如做“插、刪、改”操作需要同時修改幾個表，要求要么幾個表都修改成功，要么都不成功。begin tran 可以起到這樣的作用，它可以把若干SQL語句套在一起執(zhí)行，最后再一起commit。好處是保證了數(shù)據(jù)的一致性，但任何事情都不是完美無缺的。Begin tran付出的代價是在提交之前，所有SQL語句鎖住的資源都不能釋放，直到commit掉。

可見，如果Begin tran套住的SQL語句太多，那數(shù)據(jù)庫的性能就糟糕了。在該大事務(wù)提交之前，必然會阻塞別的語句，造成block很多。

Begin tran使用的原則是，在保證數(shù)據(jù)一致性的前提下，begin tran 套住的SQL語句越少越好！有些情況下可以采用觸發(fā)器同步數(shù)據(jù)，不一定要用begin tran。

一些SQL查詢語句應(yīng)加上nolock

在SQL語句中加nolock是提高SQL Server并發(fā)性能的重要手段，在oracle中并不需要這樣做，因為oracle的結(jié)構(gòu)更為合理，有undo表空間保存“數(shù)據(jù)前影”，該數(shù)據(jù)如果在修改中還未commit，那么你讀到的是它修改之前的副本，該副本放在undo表空間中。這樣，oracle的讀、寫可以做到互不影響，這也是oracle 廣受稱贊的地方。SQL Server 的讀、寫是會相互阻塞的，為了提高并發(fā)性能，對于一些查詢，可以加上nolock，這樣讀的時候可以允許寫，但缺點是可能讀到未提交的臟數(shù)據(jù)。使用 nolock有3條原則。

(1)    查詢的結(jié)果用于“插、刪、改”的不能加nolock ！

(2)    查詢的表屬于頻繁發(fā)生頁分裂的，慎用nolock ！

(3)    使用臨時表一樣可以保存“數(shù)據(jù)前影”，起到類似oracle的undo表空間的功能，

能采用臨時表提高并發(fā)性能的，不要用nolock 。

聚集索引沒有建在表的順序字段上，該表容易發(fā)生頁分裂

比如訂單表，有訂單編號orderid，也有客戶編號contactid，那么聚集索引應(yīng)該加在哪個字段上呢？對于該表，訂單編號是順序添加的，如果在orderid上加聚集索引，新增的行都是添加在末尾，這樣不容易經(jīng)常產(chǎn)生頁分裂。然而，由于大多數(shù)查詢都是根據(jù)客戶編號來查的，因此，將聚集索引加在contactid上才有意義。而contactid對于訂單表而言，并非順序字段。

比如“張三”的“contactid”是001，那么“張三”的訂單信息必須都放在這張表的第一個數(shù)據(jù)頁上，如果今天“張三”新下了一個訂單，那該訂單信息不能放在表的最后一頁，而是第一頁！如果第一頁放滿了呢？很抱歉，該表所有數(shù)據(jù)都要往后移動為這條記錄騰地方。

SQL Server的索引和Oracle的索引是不同的，SQL Server的聚集索引實際上是對表按照聚集索引字段的順序進行了排序，相當于oracle的索引組織表。SQL Server的聚集索引就是表本身的一種組織形式，所以它的效率是非常高的。也正因為此，插入一條記錄，它的位置不是隨便放的，而是要按照順序放在該放的數(shù)據(jù)頁，如果那個數(shù)據(jù)頁沒有空間了，就引起了頁分裂。所以很顯然，聚集索引沒有建在表的順序字段上，該表容易發(fā)生頁分裂。

曾經(jīng)碰到過一個情況，一位哥們的某張表重建索引后，插入的效率大幅下降了。估計情況大概是這樣的。該表的聚集索引可能沒有建在表的順序字段上，該表經(jīng)常被歸檔，所以該表的數(shù)據(jù)是以一種稀疏狀態(tài)存在的。比如張三下過20張訂單，而最近3個月的訂單只有5張，歸檔策略是保留3個月數(shù)據(jù)，那么張三過去的 15張訂單已經(jīng)被歸檔，留下15個空位，可以在insert發(fā)生時重新被利用。在這種情況下由于有空位可以利用，就不會發(fā)生頁分裂。但是查詢性能會比較低，因為查詢時必須掃描那些沒有數(shù)據(jù)的空位。

重建聚集索引后情況改變了，因為重建聚集索引就是把表中的數(shù)據(jù)重新排列一遍，原來的空位沒有了，而頁的填充率又很高，插入數(shù)據(jù)經(jīng)常要發(fā)生頁分裂，所以性能大幅下降。

對于聚集索引沒有建在順序字段上的表，是否要給與比較低的頁填充率？是否要避免重建聚集索引？是一個值得考慮的問題！

加nolock后查詢經(jīng)常發(fā)生頁分裂的表，容易產(chǎn)生跳讀或重復(fù)讀

加nolock后可以在“插、刪、改”的同時進行查詢，但是由于同時發(fā)生“插、刪、改”，在某些情況下，一旦該數(shù)據(jù)頁滿了，那么頁分裂不可避免，而此時nolock的查詢正在發(fā)生，比如在第100頁已經(jīng)讀過的記錄，可能會因為頁分裂而分到第101頁，這有可能使得nolock查詢在讀101頁時重復(fù)讀到該條數(shù)據(jù)，產(chǎn)生“重復(fù)讀”。同理，如果在100頁上的數(shù)據(jù)還沒被讀到就分到99頁去了，那nolock查詢有可能會漏過該記錄，產(chǎn)生“跳讀”。

上面提到的哥們，在加了nolock后一些操作出現(xiàn)報錯，估計有可能因為nolock查詢產(chǎn)生了重復(fù)讀，2條相同的記錄去插入別的表，當然會發(fā)生主鍵沖突。

使用like進行模糊查詢時應(yīng)注意

有的時候會需要進行一些模糊查詢比如

select*from contact where username like ‘%yue%’

關(guān)鍵詞%yue%，由于yue前面用到了“%”，因此該查詢必然走全表掃描，除非必要，否則不要在關(guān)鍵詞前加%，

數(shù)據(jù)類型的隱式轉(zhuǎn)換對查詢效率的影響

sql server2000的數(shù)據(jù)庫，我們的程序在提交sql語句的時候，沒有使用強類型提交這個字段的值，由sql server 2000自動轉(zhuǎn)換數(shù)據(jù)類型，會導(dǎo)致傳入的參數(shù)與主鍵字段類型不一致，這個時候sql server 2000可能就會使用全表掃描。Sql2005上沒有發(fā)現(xiàn)這種問題，但是還是應(yīng)該注意一下。

以上是寫出高性能sql的方法的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學習更多知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！

當前名稱：寫出高性能sql的方法
當前地址：http://www.rwnh.cn/article4/jdceie.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供企業(yè)網(wǎng)站制作、移動網(wǎng)站建設(shè)、自適應(yīng)網(wǎng)站、網(wǎng)站制作、微信小程序、網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)