ROWLOCK提示无效，因它仅是SQL Server优化器建议，不强制加锁；真正保障原子性的是显式事务包裹、索引驱动的行锁及带stock>0校验的单条UPDATE语句。
存储过程里用 ROWLOCK 不能保证库存扣减原子性——它只是提示，不是锁指令，真正起作用的是事务 + 行锁机制本身。
为什么 ROWLOCK 提示没用
ROWLOCK 是 SQL Server 的表提示（table hint），仅在查询语句中作为优化器建议存在，不强制加锁，也不影响更新行为。即使你写 SELECT ... WITH (ROWLOCK)，后续的 UPDATE 是否加行锁，取决于是否命中索引、事务隔离级别、语句结构等，跟这个提示无关。更关键的是：它不参与事务原子性控制，也不能防止并发覆盖。
- 常见错误现象：
UPDATE items SET stock = stock - 1 WHERE id = @id AND stock > 0加了WITH (ROWLOCK)，但依然超卖——因为该语句本身没在事务中，或 WHERE 条件未走索引导致锁升级为页锁/表锁 - 性能影响：滥用
ROWLOCK可能干扰优化器选择，反而引发锁升级或死锁 - 兼容性问题：MySQL / PostgreSQL 不支持该语法；即使在 SQL Server 中，
WITH (ROWLOCK)对UPDATE语句无效（只对SELECT生效）
真正起作用的是事务包裹 + 索引驱动的行锁
库存扣减的原子性靠的是 InnoDB（MySQL）或默认可重复读（SQL Server）下，**单条带 WHERE 条件的 UPDATE 在事务中自动加 X 锁**。重点不在提示，而在结构和执行环境：
- 必须用
BEGIN TRANSACTION显式开启事务（SQL Server）或START TRANSACTION（MySQL），否则锁在语句结束即释放，无法串行化后续逻辑 -
WHERE条件必须命中唯一索引或主键（如WHERE id = ?），否则可能锁整张表或多个页 - UPDATE 语句必须包含校验条件，例如
AND stock > 0，否则即使加了行锁，也会把 stock 扣成负数 - 务必检查
@@ROWCOUNT（SQL Server）或ROW_COUNT()（MySQL）：值为 0 表示无匹配行，即库存不足，不能当成“执行成功”
存储过程中容易被忽略的三个硬约束
写存储过程做库存扣减时，以下三点不满足，再复杂的逻辑也白搭：
- 所有 DML 操作（SELECT、UPDATE）必须在同一事务内完成；不能 SELECT 用一个事务，UPDATE 用另一个——中间窗口期就是超卖温床
- 不能依赖
SELECT stock FROM ...后再UPDATE ... SET stock = @stock - 1：这是典型的“先读后写”竞态，两事务同时读到 stock=1，都写回 0 - 存储过程不能设为
AUTOCOMMIT = ON（SQL Server 默认关，MySQL 需确认会话级设置），否则每条语句自动提交，锁立即释放
复杂逻辑（比如扣库存 + 写日志 + 更新订单状态）可以放进去，但核心扣减那一步，永远要回归到「单条带条件的 UPDATE 语句 + 显式事务」这个最简模型。其他花活，都是给这个模型加护栏，不是替代它。
