在電商、新零售等業(yè)務(wù)場景中，商品庫存的準(zhǔn)確扣減是核心且敏感的環(huán)節(jié)。完全依賴數(shù)據(jù)庫處理庫存扣減，其核心目標(biāo)是在高并發(fā)下保證數(shù)據(jù)的一致性（不超賣）、操作的原子性以及系統(tǒng)的性能。以下是幾種經(jīng)過實踐檢驗、相對“好一點兒”的數(shù)據(jù)庫處理方案。
方案一：基于樂觀鎖的版本號控制
這是最經(jīng)典且易于理解的方案。其核心思想是假設(shè)并發(fā)沖突不常發(fā)生，在更新時檢測數(shù)據(jù)是否被其他事務(wù)修改過。
實現(xiàn)方式：
1. 在商品庫存表中增加一個版本號字段（如 version，初始為0）。
2. 扣減時，將版本號作為更新條件。
UPDATE product_stock
SET stock = stock - #{purchase_quantity},
version = version + 1
WHERE id = #{product_id}
AND stock >= #{purchase_quantity}
AND version = #{current_version}; -- 帶入查詢時獲取的版本號優(yōu)點： 實現(xiàn)簡單，在沖突率低的場景下性能很好。
缺點： 在高并發(fā)搶購場景下，大量事務(wù)會因版本號不一致而更新失敗（需要業(yè)務(wù)層重試或提示用戶），成功率低。
方案二：基于數(shù)據(jù)庫行級鎖（悲觀鎖）SELECT ... FOR UPDATE
在事務(wù)內(nèi)，先鎖定要更新的庫存行，再進行操作，確保操作的串行化。
實現(xiàn)方式：`sql
BEGIN; -- 開啟事務(wù)
-- 1. 鎖定目標(biāo)行，防止其他事務(wù)修改
SELECT stock FROM productstock WHERE id = #{productid} FOR UPDATE;
-- 2. 應(yīng)用層判斷庫存是否充足
-- 3. 執(zhí)行更新
UPDATE productstock SET stock = stock - #{quantity} WHERE id = #{productid};
COMMIT; -- 提交事務(wù)`
優(yōu)點： 絕對保證一致性，邏輯簡單直接。
缺點： 性能瓶頸明顯，大量請求會排隊等待鎖，數(shù)據(jù)庫連接容易被打滿，不適合超高并發(fā)場景。
方案三：直接條件更新（無鎖方案，推薦）
這是最推薦的純數(shù)據(jù)庫扣減方案。它利用數(shù)據(jù)庫更新語句本身的原子性和行鎖，在一個SQL中完成判斷和扣減。
實現(xiàn)方式：`sql
UPDATE productstock
SET stock = stock - #{purchasequantity}
WHERE id = #{productid}
AND stock >= #{purchasequantity}; -- 核心：將庫存判斷放在WHERE條件中`
執(zhí)行后，通過判斷數(shù)據(jù)庫返回的“受影響行數(shù)”（affected rows）：
- 如果受影響行數(shù)為 1，說明扣減成功，庫存充足且已原子性扣減。
- 如果受影響行數(shù)為 0，說明扣減失敗，原因是庫存不足或商品不存在。
優(yōu)點：
1. 極致高效： 單條SQL，網(wǎng)絡(luò)開銷小，利用數(shù)據(jù)庫原生原子性，無需額外鎖。
2. 絕對安全： 在WHERE條件中校驗庫存，徹底杜絕超賣。
3. 簡單可靠： 業(yè)務(wù)邏輯清晰，依賴數(shù)據(jù)庫本身能力，維護成本低。
這是處理數(shù)據(jù)庫庫存扣減的黃金法則，在絕大多數(shù)場景下應(yīng)作為首選。
方案四：設(shè)置庫存字段為無符號整數(shù)
這是一個輔助性的“防御”策略，與上述方案結(jié)合使用。
實現(xiàn)方式：
在數(shù)據(jù)庫表設(shè)計時，將庫存字段 stock 定義為 UNSIGNED（無符號整數(shù)）。
CREATE TABLE product_stock (
id BIGINT PRIMARY KEY,
stock INT UNSIGNED NOT NULL COMMENT '庫存，無符號保證不為負'
);作用： 當(dāng)執(zhí)行 UPDATE SET stock = stock - 10 而庫存不足時，由于字段不能為負，數(shù)據(jù)庫會直接報錯（如“BIGINT UNSIGNED value is out of range”）。這可以作為防止異常數(shù)據(jù)操作的最后一道防線，但業(yè)務(wù)層仍需以方案三的條件更新為主邏輯進行友好處理。
方案五：扣減與記錄分離（預(yù)扣庫存）
對于更復(fù)雜的場景（如購物車待付款），可以引入“可用庫存”和“預(yù)扣庫存”的概念。
實現(xiàn)方式：
1. 商品表中有兩個字段：available<em>stock（可用庫存）、locked</em>stock（預(yù)扣庫存，如已下單未支付）。
2. 用戶下單時，扣減available<em>stock，同時增加locked</em>stock。
`sql
UPDATE productstock
SET availablestock = availablestock - #{quantity},
lockedstock = lockedstock + #{quantity}
WHERE id = #{productid}
AND available_stock >= #{quantity};
`
- 支付成功時，扣減
locked_stock。 - 支付超時或取消時，將
locked<em>stock加回available</em>stock。
優(yōu)點： 清晰區(qū)分庫存狀態(tài)，支持復(fù)雜的電商業(yè)務(wù)流程。
缺點： 業(yè)務(wù)邏輯和狀態(tài)機變得更復(fù)雜。
與建議
- 通用首選： 方案三（直接條件更新） 是簡單、高效、可靠的“銀彈”，應(yīng)作為滿足基礎(chǔ)扣減需求的首選。
- 組合使用： 將 方案三 與 方案四（無符號字段） 結(jié)合，實現(xiàn)代碼邏輯與數(shù)據(jù)庫級別的雙重保障。
- 場景選擇：
- 對性能要求極高，業(yè)務(wù)邏輯簡單 → 方案三。
- 需要處理中間狀態(tài)（如待支付）→ 方案五。
- 遺留系統(tǒng)或特定復(fù)雜事務(wù) → 方案二（需謹慎評估性能）。
- 必要補充： 無論采用哪種方案，都應(yīng)在數(shù)據(jù)庫表上為庫存字段和商品ID建立合適的索引，以加速更新操作。業(yè)務(wù)層必須妥善處理更新失敗（返回受影響行數(shù)為0）的情況，給用戶明確的反饋。
通過以上純數(shù)據(jù)庫層面的優(yōu)化，可以在不引入復(fù)雜中間件（如Redis）的情況下，構(gòu)建出高并發(fā)下穩(wěn)定、準(zhǔn)確的商品庫存扣減系統(tǒng)。
