库存扣减不能用先查后更新，因SELECT和UPDATE是两个独立语句，存在并发时间窗口导致超卖；必须用UPDATE...WHERE stock>=?等原子操作或SELECT FOR UPDATE悲观锁。
库存扣减为什么不能用先查后更新
因为 SELECT 和 UPDATE 是两个独立语句，中间存在时间窗口：多个并发请求同时读到相同库存值，都判断“足够”，然后都执行扣减，最终超卖。这不是程序写得不够快的问题，是数据库隔离级别无法靠应用层逻辑弥补的固有缺陷。
常见错误现象：UPDATE inventory SET stock = stock - 1 WHERE id = 1 AND stock >= 1 看似带条件，但如果没加锁且并发高，仍可能因幻读或间隙竞争导致重复扣减（尤其在可重复读下未显式加锁时）。
- 必须让“检查 + 扣减”成为不可分割的原子操作
- 要么靠数据库原生命令一次性完成（如
UPDATE ... WHERE stock >= ?），要么在事务中显式加锁 - 应用层返回影响行数为 0，就说明扣减失败，不能默认成功
用 UPDATE 的 WHERE 条件实现原子扣减（推荐首选）
这是最轻量、最高效的方式，不依赖额外锁机制，所有逻辑由单条 SQL 完成。MySQL/PostgreSQL/SQL Server 均支持。
示例（MySQL 存储过程片段）：
BEGIN
DECLARE affected_rows INT DEFAULT 0;
START TRANSACTION;
<pre class="brush:php;toolbar:false;">UPDATE inventory
SET stock = stock - 1, updated_at = NOW()
WHERE id = in_product_id AND stock >= 1;
GET DIAGNOSTICS affected_rows = ROW_COUNT();
IF affected_rows = 0 THEN
ROLLBACK;
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Insufficient stock';
ELSE
COMMIT;
END IF;END
-
WHERE stock >= 1是关键，它把校验和修改合并在同一语句中，数据库引擎内部保证原子性 - 无需
SELECT FOR UPDATE，避免长事务阻塞，吞吐更高 - 注意：该方式无法直接获取扣减前的库存值；如需记录日志或做复杂判断（比如按阶梯价扣减），才考虑加锁方案
什么时候必须用 SELECT FOR UPDATE 悲观锁
当业务逻辑无法压缩进单条 UPDATE —— 例如需要根据当前库存计算折扣、触发不同库存预警策略、或要同时更新多个关联表且依赖实时库存值时。
要点：
- 必须在事务内使用，且隔离级别至少为
READ COMMITTED（MySQL 默认REPEATABLE READ也支持） -
SELECT ... FOR UPDATE会锁定匹配的行（含间隙锁，防止插入新行干扰），其他事务对该行的SELECT FOR UPDATE或UPDATE会被阻塞 - 务必确保查询条件能命中索引，否则会升级为表锁——
WHERE id = ?没问题，WHERE product_code = ?却没建索引就会锁全表 - 锁持有时间 = 从
SELECT FOR UPDATE到COMMIT的整个事务周期，所以事务体要尽量短，别在锁内调外部 API 或做耗时计算
容易被忽略的三个细节
很多人写了 SELECT FOR UPDATE 还是超卖，往往栽在这几点：
- 没开事务：
SELECT ... FOR UPDATE在自动提交模式下是无效的，执行完立刻释放锁；必须显式START TRANSACTION或关闭 autocommit - WHERE 条件不精确：比如用
SELECT * FROM inventory WHERE product_id IN (1,2,3) FOR UPDATE，若只打算扣减其中某一个，却锁了三行，白白降低并发度 - 忽略死锁风险：两个事务分别按不同顺序锁多行（如事务 A 先锁商品1再锁商品2，事务 B 反之），就会触发死锁；应始终按固定顺序（如 ID 升序）获取锁
真正难的不是写对语法，而是想清楚：这个库存操作是否真的需要悲观锁？多数场景下，带条件的原子 UPDATE 就够了。锁是保底手段，不是默认选项。
