oracle中防超卖必须用单条update语句（如update t set stock=stock-1 where id=123 and stock>=1）并依赖影响行数判断，因其自动加行锁且条件检查与更新原子执行；子查询单独使用无法防超卖。
Oracle 中无法靠普通子查询防止超卖，必须结合行级锁或原子更新语义。子查询本身不带锁、不保证原子性，单独用 SELECT ... FROM ... WHERE stock > 0 再 UPDATE，高并发下必然超卖。
为什么子查询 + UPDATE 组合在 Oracle 中会超卖
常见错误写法是先查再更：
SELECT stock FROM products WHERE id = 123; -- 应用层判断 stock > 0 后执行： UPDATE products SET stock = stock - 1 WHERE id = 123;
问题在于：两次独立语句之间存在时间窗口，多个会话可同时读到相同 stock 值（比如都是 1），全部通过判断并执行减 1，最终 stock 变成 -2。
- Oracle 默认 READ COMMITTED 隔离级别，
SELECT不加锁，不会阻塞其他会话读 - 子查询若仅用于
WHERE条件（如UPDATE ... WHERE id IN (SELECT ...)），仍不自动加行锁，除非显式用FOR UPDATE - 即使子查询嵌套再深，只要没触发行锁或没合并为单条原子更新，就防不住并发
真正有效的 Oracle 防超卖写法：UPDATE + WHERE 检查一体化
把“库存是否充足”和“扣减”压缩进一条 UPDATE 语句，并依赖其返回影响行数判断是否成功：
UPDATE products SET stock = stock - 1 WHERE id = 123 AND stock >= 1;
执行后检查 SQL%ROWCOUNT（PL/SQL）或 JDBC 的 executeUpdate() 返回值：
- 返回 1 → 扣减成功
- 返回 0 → 库存不足或商品不存在
这个写法之所以可靠，是因为 Oracle 在执行该 UPDATE 时会对满足 WHERE 条件的行自动加行级锁（X 锁），后续并发请求会被阻塞直到前一个事务提交或回滚；且 WHERE 中的 stock >= 1 是在加锁后实时读取的当前值，不是快照值。
需要加 FOR UPDATE 的场景：业务逻辑复杂，不能单靠 UPDATE 完成
当扣减前还需查其他字段（如校验商品状态、活动时间）、或需在扣减后插入订单记录等，就必须显式加锁：
SELECT stock, status, sale_start_time, sale_end_time FROM products WHERE id = 123 FOR UPDATE NOWAIT;
FOR UPDATE NOWAIT 是关键 —— 它让 Oracle 立即尝试加锁，失败直接报 ORA-00054: resource busy，而不是挂起等待。应用层捕获该异常即可快速失败，避免线程堆积。
- 不要用
FOR UPDATE不带NOWAIT，否则高并发下大量会话排队等锁，响应雪崩 - 锁范围要精准：只查目标行，避免
SELECT ... FOR UPDATE扫描全表或大范围索引 - 事务必须短：拿到锁后尽快完成 UPDATE 和 COMMIT，不要在锁持有期间调用远程服务或做耗时计算
容易被忽略的坑：绑定变量 + 执行计划突变
如果用绑定变量写 WHERE id = :id AND stock >= :min_stock，Oracle 可能因历史统计信息生成非最优执行计划，导致跳过索引、全表扫描，进而锁住不该锁的行，甚至引发死锁。
- 确保
id字段有高效索引（最好是主键或唯一索引） - 避免在
WHERE子句中对stock列做函数操作，例如WHERE NVL(stock, 0) >= 1会失效索引 - 上线前用
EXPLAIN PLAN验证每次执行都走索引访问路径
真正防超卖的不是“有没有子查询”，而是“有没有在单次数据库操作中完成条件判断与变更”，以及“锁是否及时、精准、可控”。Oracle 的能力在线，但得用对姿势。
