避免阻塞 保障數(shù)據(jù)庫(kù)性能

申請(qǐng)免費(fèi)試用、咨詢電話：400-8352-114

雖然說(shuō)SQL Server數(shù)據(jù)庫(kù)本身提供了很好的鎖管理機(jī)制。但是，從某一方面來(lái)說(shuō)，其實(shí)數(shù)據(jù)庫(kù)只是一些客戶端應(yīng)用程序的“傀儡”。這主要是因?yàn)榭蛻舳藨?yīng)用程序?qū)Ψ?wù)器上獲取的鎖幾乎有完全的控制能力。客戶端應(yīng)用程序發(fā)出的查詢請(qǐng)求以及對(duì)結(jié)果的處理方式，往往具有直接的控制能力。所以，如果應(yīng)用程序在設(shè)計(jì)上稍有不合理的情況時(shí)，就會(huì)因?yàn)殒i機(jī)制而導(dǎo)致阻塞。

如當(dāng)遇到如下幾種情形時(shí)，就可能會(huì)導(dǎo)致阻塞情況的發(fā)生。

一、客戶端取消查詢后沒(méi)有回滾實(shí)務(wù)。

查詢是大部分應(yīng)用程序經(jīng)常發(fā)生的作業(yè)。但是，用戶通過(guò)前臺(tái)客戶端應(yīng)用程序查詢后臺(tái)數(shù)據(jù)庫(kù)時(shí)，有時(shí)候往往會(huì)因?yàn)楦鞣N原因取消查詢。如用戶打開(kāi)查詢窗口后，因?yàn)樗罊C(jī)或者用戶覺(jué)得反映速度慢強(qiáng)制取消查詢。但是，當(dāng)客戶端取消查詢時(shí)，若沒(méi)有加上回滾事務(wù)的語(yǔ)句，則此時(shí)，因?yàn)橛脩粢呀?jīng)向服務(wù)器發(fā)送了查詢請(qǐng)求，所以，后臺(tái)數(shù)據(jù)庫(kù)中所涉及的表，都已經(jīng)加L上了鎖。故即使用戶取消查詢后，所有在事務(wù)內(nèi)獲取的鎖都將會(huì)保留。此時(shí)，若其他用戶也需要查詢這些表或者用戶重新打開(kāi)查詢窗口想通過(guò)輸入查詢條件來(lái)提高系統(tǒng)響應(yīng)速度時(shí)，就會(huì)發(fā)生阻塞的現(xiàn)象。

二、客戶端沒(méi)有及時(shí)取得所有查詢的結(jié)果。

通常情況下，用戶將查詢請(qǐng)求發(fā)送到服務(wù)器之后，前臺(tái)應(yīng)用程序必須立即完成提取所有結(jié)果行。如果應(yīng)用程序沒(méi)有提取所有結(jié)果行的話，就會(huì)產(chǎn)生一個(gè)問(wèn)題。因?yàn)橹灰獞?yīng)用程序沒(méi)有及時(shí)提取所有結(jié)果，鎖可能會(huì)留在表上而阻塞其他用戶。既然應(yīng)用程序已經(jīng)將SQ語(yǔ)句遞交給服務(wù)器，則該應(yīng)用程序就必須提取所有的結(jié)果行。若應(yīng)用程序不遵循這個(gè)原則的話（如因?yàn)橐粫r(shí)疏漏而沒(méi)有配置），就無(wú)法從根本上解決阻塞問(wèn)題。

三、查詢執(zhí)行時(shí)間過(guò)長(zhǎng)。

有些查詢會(huì)耗用比較長(zhǎng)的時(shí)間。如因?yàn)椴樵冋Z(yǔ)句設(shè)計(jì)不合理或者查詢?cè)O(shè)計(jì)到的表與記錄比較多時(shí)，都會(huì)使得查詢的執(zhí)行時(shí)間加長(zhǎng)。如有時(shí)候用戶需要對(duì)紀(jì)錄進(jìn)行Update或者Delete操作時(shí)，如果涉及的行比較多時(shí)，就會(huì)獲取很多的鎖。這些鎖無(wú)論是否最終升級(jí)到表鎖，都會(huì)阻塞其他查詢。

故通常情況下，不要將長(zhǎng)時(shí)間運(yùn)行的決策支持查詢和聯(lián)機(jī)事務(wù)處理查詢混在一起。

當(dāng)數(shù)據(jù)庫(kù)遇到阻塞時(shí)，往往需要檢查應(yīng)用程序遞交的SQL語(yǔ)句本身，以及檢查與連接管理、所有結(jié)果行的處理等有關(guān)的應(yīng)用程序行為。通常情況下，為了避免因鎖沖突所導(dǎo)致的阻塞，筆者有如下建議。

建議一：查詢完成后提取所有的結(jié)果行。

有些應(yīng)用程序?yàn)榱颂岣哂脩舨樵兊捻憫?yīng)速度，會(huì)有選擇的提取所需要的記錄。這個(gè)“小聰明”看起來(lái)很合理，但是，卻會(huì)造成更大的浪費(fèi)。因?yàn)椴樵兘Y(jié)果沒(méi)有及時(shí)提取的話，鎖就不能釋放。當(dāng)其他人查詢數(shù)據(jù)時(shí)，就會(huì)發(fā)生阻塞。

所以，筆者建議在應(yīng)用程序設(shè)計(jì)時(shí)，對(duì)于數(shù)據(jù)庫(kù)中查詢的記錄要及時(shí)的提取?？梢酝ㄟ^(guò)其他方式，如添加查詢條件、或者后臺(tái)查詢的方式，來(lái)提高查詢的效率。同時(shí)，在應(yīng)用程序?qū)用嬖O(shè)置合理的緩存，也可以非常明顯的提高查詢效率。

建議二：在事務(wù)執(zhí)行時(shí)不要讓用戶輸入內(nèi)容。

雖然在事務(wù)執(zhí)性的過(guò)程中，可以讓用戶參與進(jìn)來(lái)，以提高互動(dòng)性。但是，我們數(shù)據(jù)庫(kù)管理員往往不建議這么做。因?yàn)槿粢脩粼谑聞?wù)執(zhí)行過(guò)程中輸入?yún)?shù)，會(huì)延長(zhǎng)事務(wù)的執(zhí)行時(shí)間。雖然人比較聰明，但是其反應(yīng)速度仍然沒(méi)有電腦那么快。所以，在執(zhí)行過(guò)程中加入讓用戶參與的過(guò)程，會(huì)延長(zhǎng)事務(wù)的等待時(shí)間。故除非有特殊的需要，不要在應(yīng)用程序的執(zhí)行過(guò)程中，提醒用戶輸入?yún)?shù)。一些事務(wù)執(zhí)行必須的參數(shù)，最好在事先就提供。如可以通過(guò)變量等預(yù)先把需要的參數(shù)傳入進(jìn)去。

建議三：使事務(wù)盡可能的簡(jiǎn)短。

筆者認(rèn)為，數(shù)據(jù)庫(kù)管理員應(yīng)該把一些問(wèn)題簡(jiǎn)單化。當(dāng)某個(gè)需求需要很多SQL語(yǔ)句才能夠完成時(shí)，不妨把任務(wù)進(jìn)行分解。同時(shí)，也把事務(wù)分解成一些簡(jiǎn)短的事務(wù)。

如數(shù)據(jù)庫(kù)中一張產(chǎn)品信息表，其記錄數(shù)量有二百萬(wàn)條?，F(xiàn)在處于管理的需要，把一次性更改其中的一百五十萬(wàn)條記錄時(shí)。若通過(guò)一個(gè)事務(wù)進(jìn)行更改，則其時(shí)間會(huì)比較長(zhǎng)。若其中還牽涉到級(jí)聯(lián)更新的話，則時(shí)間會(huì)更長(zhǎng)。

針對(duì)這種情況，我們就可以學(xué)著把事務(wù)簡(jiǎn)短話。如這個(gè)產(chǎn)品信息中，可能有產(chǎn)品類型字段。那么在更新數(shù)據(jù)時(shí)，我們能否不一次性進(jìn)行更新。而是通過(guò)產(chǎn)品類別字段進(jìn)行控制，對(duì)記錄進(jìn)行分次更新的。如此每個(gè)類別的更新事務(wù)所耗用的時(shí)間就可能會(huì)大大縮短。如此雖然操作的時(shí)候，會(huì)需要多個(gè)步驟。但是，往往可以有效避免阻塞情況的發(fā)生，提高數(shù)據(jù)庫(kù)的性能。

建議四：子查詢與列表框，最好不要同時(shí)使用。

有時(shí)候在應(yīng)用程序設(shè)計(jì)的時(shí)候，通過(guò)列表框確實(shí)可以提高用戶輸入的速度與準(zhǔn)確率，但是，若前臺(tái)應(yīng)用程序沒(méi)有緩存機(jī)制的話，往往會(huì)造成阻塞。

如在一個(gè)訂單管理系統(tǒng)中，可能需要頻繁的輸入銷售代表。為了用戶輸入的方便，銷售代表往往設(shè)計(jì)成一個(gè)列表框。每次需要輸入時(shí)，前臺(tái)應(yīng)用程序都會(huì)從后臺(tái)中進(jìn)行查詢銷售代表信息（如果應(yīng)用程序沒(méi)有涉及緩存）。一方面，子查詢的速度本來(lái)就比較慢；其次，列表框會(huì)生成長(zhǎng)時(shí)間運(yùn)行的查詢。這兩個(gè)方面碰在一起，就可能導(dǎo)致應(yīng)用程序提高運(yùn)行時(shí)間過(guò)程的查詢。從而對(duì)其他用戶的查詢，如系統(tǒng)管理員需要維護(hù)用戶信息，而造成阻塞。

所以，在應(yīng)用程序設(shè)計(jì)時(shí)，子查詢最好少用。而子查詢與列表框同時(shí)使用，更需要禁止。若避免不了的話，則要在應(yīng)用程序中實(shí)現(xiàn)緩存機(jī)制。如此的話，應(yīng)用程序需要銷售代表信息的時(shí)候，就會(huì)從應(yīng)用程序緩存中取得，而不會(huì)每次都去查詢數(shù)據(jù)庫(kù)。

同時(shí)，可以在這個(gè)列表框中設(shè)計(jì)“重新查詢”功能。當(dāng)用戶信息有變更，如系統(tǒng)管理員加入了一個(gè)新的銷售代表。在沒(méi)有進(jìn)行重新查詢之前，由于應(yīng)用程序是從自身的緩存中取得數(shù)據(jù)，所以沒(méi)有剛更新的內(nèi)容。此時(shí)，用戶就需要運(yùn)行重新查詢功能，讓前臺(tái)應(yīng)用程序重新從數(shù)據(jù)庫(kù)中查詢信息。這種設(shè)計(jì)，就可以提高列表框與子查詢的執(zhí)行時(shí)間，有效避免阻塞問(wèn)題。

建議五：在取消查詢時(shí)設(shè)置回退事務(wù)。

前臺(tái)應(yīng)用程序設(shè)計(jì)時(shí)，應(yīng)該允許用戶臨時(shí)改變主意，取消查詢。如用戶查詢所有產(chǎn)品信息時(shí)，可能會(huì)覺(jué)得響應(yīng)時(shí)間比較長(zhǎng)，難以忍受。此時(shí)，他們就會(huì)想到取消查詢。在這種情況下，應(yīng)用程序設(shè)計(jì)時(shí)就需要設(shè)計(jì)一個(gè)取消查詢按鈕。用戶可以在查詢的過(guò)程中隨時(shí)點(diǎn)擊這個(gè)按鈕取消查詢。同時(shí)，在這個(gè)按鈕事件中，需要注意加入一個(gè)回滾命令。讓數(shù)據(jù)庫(kù)服務(wù)器能夠及時(shí)對(duì)相關(guān)記錄或者表進(jìn)行解鎖。

同時(shí)最好能夠采用鎖或者查詢超時(shí)機(jī)制。這主要是因?yàn)?，有時(shí)候大量查詢也會(huì)耗費(fèi)用戶主機(jī)的大量資源，而導(dǎo)致客戶機(jī)死機(jī)。此時(shí)，若能夠采用查詢或者鎖超時(shí)機(jī)制，即在查詢超時(shí)過(guò)后，數(shù)據(jù)庫(kù)服務(wù)器自動(dòng)對(duì)相關(guān)對(duì)象進(jìn)行解鎖。這也是數(shù)據(jù)庫(kù)管理員需要跟程序開(kāi)發(fā)人員協(xié)商的一個(gè)問(wèn)題。

另外，對(duì)數(shù)據(jù)庫(kù)連接采取顯式控制、在所預(yù)計(jì)的并發(fā)用戶全負(fù)荷下對(duì)應(yīng)用程序進(jìn)行承受能力測(cè)試、使用邦定連接、對(duì)每個(gè)查詢使用查詢超時(shí)與鎖超時(shí)等等，這些手段都可以有效避免鎖沖突產(chǎn)生的阻塞。當(dāng)數(shù)據(jù)庫(kù)管理員發(fā)現(xiàn)有阻塞的癥狀時(shí)，可以從這些方面出發(fā)，尋找解決的措施。

從以上的分析中可以看出，SQL Server數(shù)據(jù)庫(kù)鎖是一把雙刃劍。其在保障數(shù)據(jù)庫(kù)數(shù)據(jù)一致性的同時(shí)，也會(huì)給數(shù)據(jù)庫(kù)造成一些負(fù)面影響。如何把這些負(fù)面影響降到最低，就是我們數(shù)據(jù)庫(kù)管理員的任務(wù)。在應(yīng)用程序設(shè)計(jì)時(shí)，遵循如上建議，可以有效解決因鎖問(wèn)題產(chǎn)生的阻塞問(wèn)題，提高數(shù)據(jù)庫(kù)的性能?？梢?jiàn)，要從根本上解決阻塞問(wèn)題，需要數(shù)據(jù)庫(kù)管理人員與程序開(kāi)發(fā)人員共同努力。（IT專家網(wǎng)）