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

申請免費試用、咨詢電話：400-8352-114

雖然說SQL Server數(shù)據庫本身提供了很好的鎖管理機制。但是，從某一方面來說，其實數(shù)據庫只是一些客戶端應用程序的“傀儡”。這主要是因為客戶端應用程序對服務器上獲取的鎖幾乎有完全的控制能力。客戶端應用程序發(fā)出的查詢請求以及對結果的處理方式，往往具有直接的控制能力。所以，如果應用程序在設計上稍有不合理的情況時，就會因為鎖機制而導致阻塞。

如當遇到如下幾種情形時，就可能會導致阻塞情況的發(fā)生。

一、客戶端取消查詢后沒有回滾實務。

查詢是大部分應用程序經常發(fā)生的作業(yè)。但是，用戶通過前臺客戶端應用程序查詢后臺數(shù)據庫時，有時候往往會因為各種原因取消查詢。如用戶打開查詢窗口后，因為死機或者用戶覺得反映速度慢強制取消查詢。但是，當客戶端取消查詢時，若沒有加上回滾事務的語句，則此時，因為用戶已經向服務器發(fā)送了查詢請求，所以，后臺數(shù)據庫中所涉及的表，都已經加L上了鎖。故即使用戶取消查詢后，所有在事務內獲取的鎖都將會保留。此時，若其他用戶也需要查詢這些表或者用戶重新打開查詢窗口想通過輸入查詢條件來提高系統(tǒng)響應速度時，就會發(fā)生阻塞的現(xiàn)象。

二、客戶端沒有及時取得所有查詢的結果。

通常情況下，用戶將查詢請求發(fā)送到服務器之后，前臺應用程序必須立即完成提取所有結果行。如果應用程序沒有提取所有結果行的話，就會產生一個問題。因為只要應用程序沒有及時提取所有結果，鎖可能會留在表上而阻塞其他用戶。既然應用程序已經將SQ語句遞交給服務器，則該應用程序就必須提取所有的結果行。若應用程序不遵循這個原則的話（如因為一時疏漏而沒有配置），就無法從根本上解決阻塞問題。

三、查詢執(zhí)行時間過長。

有些查詢會耗用比較長的時間。如因為查詢語句設計不合理或者查詢設計到的表與記錄比較多時，都會使得查詢的執(zhí)行時間加長。如有時候用戶需要對紀錄進行Update或者Delete操作時，如果涉及的行比較多時，就會獲取很多的鎖。這些鎖無論是否最終升級到表鎖，都會阻塞其他查詢。

故通常情況下，不要將長時間運行的決策支持查詢和聯(lián)機事務處理查詢混在一起。

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

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

有些應用程序為了提高用戶查詢的響應速度，會有選擇的提取所需要的記錄。這個“小聰明”看起來很合理，但是，卻會造成更大的浪費。因為查詢結果沒有及時提取的話，鎖就不能釋放。當其他人查詢數(shù)據時，就會發(fā)生阻塞。

所以，筆者建議在應用程序設計時，對于數(shù)據庫中查詢的記錄要及時的提取?？梢酝ㄟ^其他方式，如添加查詢條件、或者后臺查詢的方式，來提高查詢的效率。同時，在應用程序層面設置合理的緩存，也可以非常明顯的提高查詢效率。

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

雖然在事務執(zhí)性的過程中，可以讓用戶參與進來，以提高互動性。但是，我們數(shù)據庫管理員往往不建議這么做。因為若要用戶在事務執(zhí)行過程中輸入參數(shù)，會延長事務的執(zhí)行時間。雖然人比較聰明，但是其反應速度仍然沒有電腦那么快。所以，在執(zhí)行過程中加入讓用戶參與的過程，會延長事務的等待時間。故除非有特殊的需要，不要在應用程序的執(zhí)行過程中，提醒用戶輸入參數(shù)。一些事務執(zhí)行必須的參數(shù)，最好在事先就提供。如可以通過變量等預先把需要的參數(shù)傳入進去。

建議三：使事務盡可能的簡短。

筆者認為，數(shù)據庫管理員應該把一些問題簡單化。當某個需求需要很多SQL語句才能夠完成時，不妨把任務進行分解。同時，也把事務分解成一些簡短的事務。

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

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

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

有時候在應用程序設計的時候，通過列表框確實可以提高用戶輸入的速度與準確率，但是，若前臺應用程序沒有緩存機制的話，往往會造成阻塞。

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

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

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

建議五：在取消查詢時設置回退事務。

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

同時最好能夠采用鎖或者查詢超時機制。這主要是因為，有時候大量查詢也會耗費用戶主機的大量資源，而導致客戶機死機。此時，若能夠采用查詢或者鎖超時機制，即在查詢超時過后，數(shù)據庫服務器自動對相關對象進行解鎖。這也是數(shù)據庫管理員需要跟程序開發(fā)人員協(xié)商的一個問題。

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

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