直接UPDATE WHERE仍可能超卖，因其仅原子校验当前库存是否充足，却无法阻止其他事务在执行前读到旧值并发扣减；若WHERE条件未命中唯一索引，还可能引发间隙锁或表锁，导致阻塞或失效。
为什么直接UPDATE WHERE还是可能超卖
很多人写 UPDATE inventory SET stock = stock - 1 WHERE sku = @sku AND stock >= @need，以为加了 stock >= @need 就万无一失。但问题在于：这个语句本身是原子的，可它只校验“当前值是否够”，不阻止其他事务在你执行前读到旧值并发起并发扣减——尤其当应用层做了缓存、重试或二次校验时，逻辑就脱钩了。更隐蔽的是，如果 WHERE 条件没走索引（比如 sku 字段没建唯一索引），MySQL 可能升级为间隙锁甚至表锁，而 SQL Server 在某些执行计划下也可能锁范围过大，导致误阻塞。
SQL Server 必须用 UPDLOCK + HOLDLOCK 做 SELECT
在事务中第一句就执行带锁的查询，才是把「读+改」真正捏成原子动作的关键。不能只靠后续 UPDATE 的行锁，因为那是在你读完之后才加的，中间有窗口。
-
SELECT @cur_stock = stock FROM inventory WHERE sku = @sku WITH (UPDLOCK, HOLDLOCK)—— 这行必须在BEGIN TRANSACTION之后、任何业务判断之前 -
UPDLOCK确保别人不能同时对这行加更新锁；HOLDLOCK等价于SERIALIZABLE，让锁持续到事务结束，不是语句结束 - 后续
UPDATE不需要再加提示，SQL Server 会复用已持有的更新锁 - 如果
@cur_stock < @need，必须立刻ROLLBACK或THROW，不能只返回错误消息后继续执行
MySQL 存储过程里 FOR UPDATE 必须配唯一索引
MySQL 没有 WITH (UPDLOCK)，只能靠 SELECT ... FOR UPDATE。但它非常挑剔：WHERE 条件字段若没有唯一索引，InnoDB 可能锁住整个索引范围（间隙锁），甚至退化为表锁，引发大面积阻塞。
- 确保
sku字段有UNIQUE INDEX，而不是普通索引或没索引 - 写法必须是：
SELECT stock INTO @cur_stock FROM inventory WHERE sku = @sku FOR UPDATE，且整句要在BEGIN ... COMMIT内 - 不要在
FOR UPDATE和UPDATE之间做耗时操作（如调用外部 API、复杂计算），锁持有时间越长，并发吞吐越低 - 失败时不能只
SELECT 'error'，得用SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'stock not enough'或显式ROLLBACK
sp_getapplock 是伪解药，别用在库存场景
有人想绕开数据库锁，用 sp_getapplock 锁住 'stock_' + @sku。这看似隔离了 SKU 级别，实际危险很大：
- 它不和数据行绑定——另一个会话完全可以绕过锁，直接
UPDATE inventory SET stock = stock - 1 WHERE sku = @sku，照样成功 - 锁名长度限制 255 字符，拼接业务字段容易截断，导致不同 SKU 锁名碰撞
- 默认绑定事务，但一旦存储过程异常退出没
COMMIT/ROLLBACK，锁就永远挂着，新连接会被静默卡死 - 返回值必须检查：
IF @result < 0才算失败；只看@@ERROR会漏掉超时（-1）和死锁牺牲（-2）
真正容易被忽略的点是：锁机制选型不是比“谁更高级”，而是看它能不能覆盖所有写路径。只要有一个接口、一个 Job、一个迁移脚本绕过你的锁逻辑，一致性就崩了。所以优先用数据库原生行级锁，而不是在应用层叠一层不可靠的互斥。
