資料庫管理系統 - 死鎖：理解與防止數據庫瓶頸

Hello，有志於數據庫的愛好者們！我很興奮能夠引導你們進入數據庫管理系統（DBMS）的迷人世界，以及其中最棘手的概念之一：死鎖。如果你是編程新手，別擔心；我們會從基礎開始，逐步深入。在這個教程結束時，你將成為一名死鎖偵探，能夠發現和防止這些討厭的數據庫瓶頸！

DBMS - Deadlock

什麼是死鎖？

想像你和你的朋友坐在一張只有一把叉子和一把刀的桌子上。你們都需要這兩個餐具才能進食，但你們各自拿著一個並拒絕放手，直到你們得到另一個。這基本上就是數據庫世界中死鎖的情景！

在DBMS術語中，當兩個或多個交易正在等待對方釋放他們持有的資源時，就會發生死鎖。這就像數字化的墨西哥對峙，沒有人能夠向前移動。

讓我們看一個簡單的例子：

-- 交易 1
BEGIN TRANSACTION;
UPDATE Accounts SET Balance = Balance - 100 WHERE AccountID = 1;
UPDATE Accounts SET Balance = Balance + 100 WHERE AccountID = 2;
COMMIT;

-- 交易 2
BEGIN TRANSACTION;
UPDATE Accounts SET Balance = Balance - 50 WHERE AccountID = 2;
UPDATE Accounts SET Balance = Balance + 50 WHERE AccountID = 1;
COMMIT;

在這個場景中，如果交易 1 更新賬戶 1 而交易 2 更新賬戶 2 同時發生，他們可能會無限期地等待對方，從而創造出一個死鎖。

死鎖預防

既然我們理解了什麼是死鎖，讓我們來探討如何預防它。死鎖預防涉及將系統結構化，以消除發生死鎖的可能性。

1. 資源排序

一種有效的方法是總是按照特定的順序請求資源。這就像告訴我們的進食者先拿起叉子，然後再拿起刀。這樣，他們就不會處於彼此持有對方所需餐具的狀況。

以下是我們如何重寫前面的例子以防止死鎖：

-- 交易 1
BEGIN TRANSACTION;
UPDATE Accounts SET Balance = Balance - 100 WHERE AccountID = 1;
UPDATE Accounts SET Balance = Balance + 100 WHERE AccountID = 2;
COMMIT;

-- 交易 2
BEGIN TRANSACTION;
UPDATE Accounts SET Balance = Balance - 50 WHERE AccountID = 1;
UPDATE Accounts SET Balance = Balance + 50 WHERE AccountID = 2;
COMMIT;

通過總是先更新賬戶 1，我們確保交易不會死鎖。

2. 鎖定超時

另一種預防方法是使用鎖定超時。這就像告訴我們的進食者：“如果你在 5 分鐘內無法得到兩個餐具，那就放棄，稍後再試。”

在 SQL Server 中，你可以這樣設置鎖定超時：

SET LOCK_TIMEOUT 5000; -- 設置超時為 5 秒

這樣，如果一個交易在 5 秒內無法獲得鎖定，它將自動回滾，防止潛在的死鎖。

3. 縮短鎖定時間

資源被鎖定的时间越短，發生死鎖的機會就越小。這就像告訴我們的進食者吃得更快！在數據庫術語中，這意味著將交易保持得盡可能短暫。

以下是如何減少鎖定時間的例子：

-- 而不是這樣：
BEGIN TRANSACTION;
-- 進行一些長時間的處理
UPDATE Accounts SET Balance = Balance - 100 WHERE AccountID = 1;
COMMIT;

-- 像這樣：
-- 進行一些長時間的處理
BEGIN TRANSACTION;
UPDATE Accounts SET Balance = Balance - 100 WHERE AccountID = 1;
COMMIT;

通過將長時間的處理移出交易，我們減少了鎖定時間。

死鎖避免

雖然預防旨在使死鎖不可能發生，但避免則是在運行時做出智能決策以避開潛在的死鎖。

1. 等待-死亡方案

在這種方案中，較老的交易會被給予優先權。如果較年輕的交易請求一個被較老交易持有的資源，它會“死亡”（回滾）並重新啟動。如果較老的交易請求一個被較年輕的交易持有的資源，它會等待。

以下是一個伪代碼表示：

def request_resource(transaction, resource):
if resource.is_held_by_younger_transaction(transaction):
wait(transaction, resource)
else:
die_and_restart(transaction)

2. 伤害-等待方案

這是等待-死亡方案的相反方案。較老的交易“伤害”（回滾）較年輕的交易，而較年輕的交易等待較老的交易。

def request_resource(transaction, resource):
if resource.is_held_by_younger_transaction(transaction):
wound(resource.holder)
else:
wait(transaction, resource)

3. 銀行家算法

這個以銀行貸款實踐命名的巧妙算法決定是否批准資源請求可能会导致死鎖。如果可能，請求將被拒絕。

以下是一個簡化的銀行家算法：

def is_safe_state(available, max_need, allocation):
work = available.copy()
finish = [False] * len(allocation)

while True:
found = False
for i in range(len(allocation)):
if not finish[i] and (max_need[i] - allocation[i] <= work).all():
work += allocation[i]
finish[i] = True
found = True

if not found:
break

return all(finish)

def request_resources(process_id, request):
if request > max_need[process_id] - allocation[process_id]:
return False  # 請求超過最大聲明

if request > available:
return False  # 資源不可用

# 暫時分配資源
available -= request
allocation[process_id] += request

if is_safe_state(available, max_need, allocation):
return True  # 批准請求
else:
# 返回更改並拒絕請求
available += request
allocation[process_id] -= request
return False

這個算法檢查批准請求是否會使系統處於安全狀態（所有進程都能完成）。如果不是，它將拒絕請求。

結論

恭喜你！你剛剛踏入了死鎖預防和避免的世界。記住，處理死鎖就像在繁忙的路口當交通警察。有時候你需要預防問題發生（比如設置交通信號燈），而有時候你需要迅速做出決策以避免事故（比如手動指揮交通）。

隨著你在數據庫管理領域的進一步探索，你將會遇到更多複雜的場景，但我們在這裡討論的原則將為你提供堅實的基礎。持續練習，保持好奇心，並不害怕嘗試。畢竟，每個偉大的數據庫管理員都是从你現在的位置開始的！

快樂編程，願你的交易總是免於死鎖！

Credits: Image by storyset