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