大型SQL Server數據庫vs死鎖？

Question

我正在查看一個SQLServer數據庫，其大小爲751 GB，並且在100個擁有多個用戶的國家/地區訪問。

自從最近幾個月以來，該數據庫在少數表格上遇到了死鎖。

我懷疑這個巨大的大小可能會對數據庫鎖造成影響。我查看索引和存儲過程，並在使用select查詢時在表上應用update lock。

仍然沒有影響。

Answer 1

如果有用戶只使用表格進行報告（並且他們查詢的數據變化不太快），他們總是可以使用SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED功能。

運行select語句時，這不會鎖定表。但是，您確實需要明智地使用它......因爲許多SQL專家會告訴您，您的結果可能不正確。但是，它可能有助於降低您看到的死鎖數量。

檢查此頁以瞭解更多資訊https://en.wikipedia.org/wiki/Isolation_%28database_systems%29#READ_UNCOMMITTED_.28dirty_reads.29

Answer 2

您需要分析在死鎖發生。它與你的數據庫的大小（或者它正在使用的國家數量）沒有任何關係。它只是訪問數據的一個問題，以及使用數據庫的應用程序的行爲模式。

通常，當一個進程正在讀取記錄並且另一個進程正在更新它們時，會發生死鎖，並且它們都需要獲得對數據的更多鎖定，但無法執行，因爲另一個鎖定已經鎖定了這些行並且它們都不能繼續，直到另一個完成 - 並且此時SQL Server發現問題併發生死鎖。

死鎖可能發生在數據或索引上，您應該檢查它是哪一個，它可能會幫助您確定發生了什麼。

爲了解決這個問題，如果您可以更改模式，以便始終以相同順序訪問數據，則不應出現死鎖。

另一種方法是查看語句並查看涉及多少I/O。如果語句涉及例如掃描，則創建新索引可能會解決問題。然後該過程需要訪問的頁面少得多，並且死鎖的機會將減少。

如果它的數據庫很繁忙，並且始終在同一張表上發生很多不同的動作，它可能無法擺脫所有的死鎖，所以你也應該想出一個目標，多少個死鎖就可以了。

我個人會遠離髒讀（隔離級別讀未提交/使用NOLOCK），除了一些非常特殊的情況下使用它可能會有所幫助，因爲它可能會導致嚴重的副作用，如閱讀相同的數據不止一次。這當然很大程度上取決於您所處理的數據/應用程序的類型。