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