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

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

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

1. 悲觀鎖（Pessimistic Locking）

核心思想

假設(shè)數(shù)據(jù)會(huì)被頻繁修改，因此提前對數(shù)據(jù)進(jìn)行加鎖，防止其他事務(wù)訪問，直到當(dāng)前事務(wù)完成操作并釋放鎖。

實(shí)現(xiàn)方式

顯式加鎖：通過 SQL 語句主動(dòng)申請鎖。

排他鎖（X Lock）：

SELECT ... FOR UPDATE

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

共享鎖（S Lock）：

SELECT ... LOCK IN SHARE MODE

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

隱式加鎖：數(shù)據(jù)庫自動(dòng)管理（如 MySQL 的 InnoDB 引擎默認(rèn)使用行級(jí)鎖）。

適用場景

寫多讀少的場景（如頻繁更新的數(shù)據(jù)）。
需要強(qiáng)一致性且沖突概率較高時(shí)（如金融交易）。

示例

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)點(diǎn)：

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

缺點(diǎn)：

可能導(dǎo)致死鎖（需應(yīng)用層處理）。
降低并發(fā)性能（長時(shí)間持有鎖會(huì)阻塞其他操作）。

2. 樂觀鎖（Optimistic Locking）

核心思想

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

實(shí)現(xiàn)方式

版本號(hào)（Version）：在表中增加 version 字段，更新時(shí)驗(yàn)證版本號(hào)。

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

時(shí)間戳（Timestamp）：類似版本號(hào)，但使用時(shí)間戳標(biāo)記數(shù)據(jù)修改時(shí)間。
CAS（Compare-And-Swap）：在應(yīng)用層比較數(shù)據(jù)一致性后再提交。

適用場景

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

示例

-- 初始查詢（獲取當(dāng)前版本號(hào)）
SELECT balance, version FROM accounts WHERE user_id = 1;

-- 更新時(shí)檢查版本號(hào)
UPDATE accounts 
SET 
  balance = balance - 100, 
  version = version + 1 
WHERE 
  user_id = 1 AND version = 1; -- 假設(shè)舊版本號(hào)是1

-- 如果受影響行數(shù)=0，說明版本已過期，需重試或報(bào)錯(cuò)

優(yōu)點(diǎn)：

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

缺點(diǎn)：

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

3. 對比總結(jié)

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