資源描述：
《sqlserver優(yōu)化性能入門》由會(huì)員上傳分享，免費(fèi)在線閱讀，更多相關(guān)內(nèi)容在應(yīng)用文檔-天天文庫。
1、SQLServer優(yōu)化性能入門第一步，在業(yè)務(wù)高峰期抓取樣本數(shù)據(jù)（2個(gè)小時(shí)左右）。采用的工具是sqlserver自帶的profiler，也叫事件探查器，如下圖：進(jìn)入后，點(diǎn)擊最左面的按鈕，建立一個(gè)新的跟蹤：登錄需要用DBO權(quán)限，所以可以用sa登錄，也可以用windows集成驗(yàn)證方式（如果當(dāng)前登錄的就是sqlserver的話）新建跟蹤，一共有4個(gè)tab頁進(jìn)行配置，首先看第一個(gè)。跟蹤名稱不用更改，默認(rèn)的即可。保存一共有兩種方式，一是文件，擴(kuò)展名是.trc（這種方式方便你把客戶那里的跟蹤結(jié)果發(fā)給你），其二是數(shù)據(jù)庫中的表。為了分析方便，我們把它另存為表。此時(shí)
2、sql提示你重新進(jìn)行登錄，這里我們把表保存到master中假設(shè)表名字叫做jq（如果有重復(fù)的，系統(tǒng)會(huì)提示是否覆蓋）確定后回到了剛才的第一個(gè)tab頁中：然后切換到第二個(gè)選項(xiàng)卡中：左面列出了各種事件類（EventClass），右面是當(dāng)前已有的事件類。對于性能調(diào)優(yōu)，我們不需要安全審核、會(huì)話信息，點(diǎn)擊刪除按鈕即可：繼續(xù)切換到第三個(gè)tab頁上，這里的數(shù)據(jù)列默認(rèn)就夠了，當(dāng)然，如果你看著不順眼，可以把Appname/NTusername等都刪除。最后一個(gè)tab頁上，我們需要把系統(tǒng)自己產(chǎn)生的事件ID屏蔽掉：把那個(gè)排除系統(tǒng)ID進(jìn)行check即可，如下圖：所有項(xiàng)目配置
3、好后，點(diǎn)擊“運(yùn)行”按鈕。持續(xù)運(yùn)行兩個(gè)小時(shí)左右即可（業(yè)務(wù)高峰期，能典型的反應(yīng)客戶最近一段時(shí)間內(nèi)的業(yè)務(wù)模式）好了，第一步的準(zhǔn)備工作完成了，等待一段時(shí)間后，我們開始檢查剛才自動(dòng)保存到master中的表jq。第二步，開始查找影響速度的地方。打開查詢分析器（sqlanalyzer），登錄到master中，從表jq里面按照I/O倒序，讀取若干個(gè)sql。根據(jù)我的習(xí)慣，一般是讀取1000條記錄。為什么根據(jù)I/O來找呢，而不是根據(jù)時(shí)間來找呢？原因很簡單，一句SQL執(zhí)行，“穩(wěn)定”的是I/O，而duration是一個(gè)不穩(wěn)定的因素。我們進(jìn)行sql調(diào)優(yōu)的目的，就是降低I/
4、O成本，從而提高效率。（一般而言，I/O降低了，duration自然就會(huì)降低）詳細(xì)內(nèi)容，參考我以前的post：http://blog.joycode.com/juqiang執(zhí)行完成后，我們仔細(xì)看下面的輸出。1、XL_TALLY_Proc04這個(gè)sp的reads最大，將近100w，duration也達(dá)到了25秒多。2、Erp_IM_GMBill_GetBill這個(gè)sp的I/O不算大，才7w，duration平均都在1秒多點(diǎn)。但是這個(gè)sp執(zhí)行的次數(shù)非常多。經(jīng)過詢問客戶，XL_TALLY_Proc04這個(gè)sp執(zhí)行的頻度很低，一天也就一兩次，但是Erp_
5、IM_GMBill_GetBill大概5分鐘就要一次。這樣整體I/O就占用的非常大。所以這里我們要重點(diǎn)分析Erp_IM_GMBill_GetBill這個(gè)sp，而不是第一個(gè)！總結(jié)一個(gè)原則就是：調(diào)整的重點(diǎn)是客戶最關(guān)心的內(nèi)容，是執(zhí)行頻度最高、看起來I/O又比較大的那種。I/O最大的，不一定是我們要優(yōu)先解決的內(nèi)容。第三步，開始分析剛才看到的那個(gè)語句。既然我們要分析I/O，那么就要把I/O打開，這樣每次調(diào)整sql，我們都能隨時(shí)看到I/O的變化情況。這句很有用處地：setstatisticsioon單純看I/O變化，我們會(huì)暈倒的。因?yàn)槲覀儾恢雷约鹤龅娜魏胃?/p>
6、動(dòng)，對I/O是如何產(chǎn)生影響的。所以，還要看sql的執(zhí)行計(jì)劃是怎佯的。在查詢分析器中，我們按Ctrl+K，或者如下圖的菜單，check上即可。好了，準(zhǔn)備工作都做好了，下面開始干活了。我們首先看sql語句的調(diào)優(yōu)，假設(shè)下面這條sql語句性能低下：上面的sql一共讀取了6636條數(shù)據(jù)，邏輯讀是1126。那么這個(gè)I/O是否合理呢？大了還是小了？還有改進(jìn)的余地嗎？我們看執(zhí)行計(jì)劃：哦，一共4個(gè)咚咚在里面。Indexseek的成本占了2%，indexscan的占了47%，hashmatch占了51%，select最終是0%。我們應(yīng)該牢記第二個(gè)原則，所有的inde
7、x，盡可能的都走indexseek。我們看一下billsoflading的索引信息：當(dāng)前索引為什么走scan，這里就不說了，感興趣的可以隨便找一本介紹數(shù)據(jù)庫索引的書籍來看看即可。根據(jù)我以前那篇blog的描述，我們知道應(yīng)該建立一個(gè)復(fù)合索引（也叫converedindex）：boldate+companyid+bolcode然后我們重新執(zhí)行sql，看看I/O變化情況：Ooh，非常cool！logicalreads降低到了50。為什么會(huì)這樣呢？我們看一下執(zhí)行計(jì)劃：原來是indexscan變成了indexseek，效率自然大大的提升！Sql語句在inde
8、x上調(diào)優(yōu)的方法，基本就是這樣。我們繼續(xù)看sp的。對于sp的調(diào)優(yōu)，有一點(diǎn)是和sql調(diào)優(yōu)不同的：sp內(nèi)部的邏輯處理可能非常復(fù)雜。單純從查詢分
