MySQL中的樂觀鎖和悲觀鎖的區(qū)別及說明

更新時間：2025年05月09日 10:06:51 作者：籬笆院的狗

這篇文章主要介紹了MySQL中的樂觀鎖和悲觀鎖的區(qū)別及說明,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教

1. 悲觀鎖（Pessimistic Locking）

核心思想

假設數據會被頻繁修改，因此提前對數據進行加鎖，防止其他事務訪問，直到當前事務完成操作并釋放鎖。

實現方式

顯式加鎖：通過 SQL 語句主動申請鎖。

排他鎖（X Lock）：

SELECT ... FOR UPDATE

（在事務中鎖定選中的行，阻止其他事務修改或加鎖）

共享鎖（S Lock）：

SELECT ... LOCK IN SHARE MODE

（允許其他事務讀，但阻止寫操作）

隱式加鎖：數據庫自動管理（如 MySQL 的 InnoDB 引擎默認使用行級鎖）。

適用場景

寫多讀少的場景（如頻繁更新的數據）。
需要強一致性且沖突概率較高時（如金融交易）。

示例

START TRANSACTION;
-- 鎖定用戶賬戶余額（排他鎖）
SELECT balance FROM accounts WHERE user_id = 1 FOR UPDATE;
-- 執(zhí)行扣款操作
UPDATE accounts SET balance = balance - 100 WHERE user_id = 1;
COMMIT;

優(yōu)點：

保證數據操作的原子性和一致性。
適合高競爭場景（沖突概率高時效率更高）。

缺點：

可能導致死鎖（需應用層處理）。
降低并發(fā)性能（長時間持有鎖會阻塞其他操作）。

2. 樂觀鎖（Optimistic Locking）

核心思想

假設數據沖突較少發(fā)生，因此不加鎖，而是在更新時檢查數據是否被修改過。若被修改過，則拒絕操作或重試。

實現方式

版本號（Version）：在表中增加 version 字段，更新時驗證版本號。

UPDATE table 
SET 
  column = new_value, 
  version = version + 1 
WHERE 
  id = 1 AND version = old_version;

時間戳（Timestamp）：類似版本號，但使用時間戳標記數據修改時間。
CAS（Compare-And-Swap）：在應用層比較數據一致性后再提交。

適用場景

讀多寫少的場景（如商品庫存充足時的秒殺）。
沖突概率較低時（如用戶點贊操作）。

示例

-- 初始查詢（獲取當前版本號）
SELECT balance, version FROM accounts WHERE user_id = 1;

-- 更新時檢查版本號
UPDATE accounts 
SET 
  balance = balance - 100, 
  version = version + 1 
WHERE 
  user_id = 1 AND version = 1; -- 假設舊版本號是1

-- 如果受影響行數=0，說明版本已過期，需重試或報錯

優(yōu)點：

無鎖競爭，并發(fā)性能高。
避免死鎖問題。

缺點：

沖突發(fā)生時需處理重試邏輯（如循環(huán)重試或返回錯誤）。
無法保證強一致性（最終一致性）。

3. 對比總結

特性	悲觀鎖	樂觀鎖
加鎖時機	操作前加鎖	操作后驗證
實現復雜度	依賴數據庫機制	需應用層配合（如版本號）
并發(fā)性能	較低（鎖競爭）	較高（無鎖）
適用場景	高競爭、強一致性	低競爭、最終一致性
典型問題	死鎖、性能瓶頸	版本沖突、重試邏輯