MySQL中UPDATE的WHERE子查询必须置于WHERE条件中而非SET子句，因SET中的子查询无法保证原子性校验，仅WHERE中的子查询可触发当前读并确保库存等业务逻辑安全扣减。
UPDATE WHERE 子查询必须写在 WHERE 条件里，不能放 SET 中
很多人误把库存校验逻辑塞进 SET 语句，比如写成 UPDATE products SET stock = (SELECT stock FROM products WHERE id = 123) - 1 WHERE id = 123。这看似原子，实则危险：子查询执行时可能读到旧快照（尤其在 RR 隔离级别下），而后续赋值不校验是否够扣，直接覆盖。真正安全的是让子查询参与条件判断——只有校验通过才允许更新。
-
WHERE中的子查询触发一次独立的当前读（或加锁读），比主表行的可见性更可靠 - 若子查询返回空（如商品不存在）或非单值，语句直接失败，不会误扣
- MySQL 8.0+ 支持
WITH公共表表达式提前计算，但最终仍需落在WHERE条件中生效
FOR UPDATE + 子查询组合只锁目标行，不锁子查询表
当校验逻辑涉及多表（比如查订单数量再比对仓库库存），常用 SELECT ... FOR UPDATE 加锁后判断。但要注意：子查询里的表（如 order_items）只是被读，不会被锁住。锁只落在主 SELECT 的目标表（如 warehouse_stock）上。
- 错误写法：
SELECT * FROM warehouse_stock WHERE sku_id = 456 AND stock >= (SELECT qty FROM order_items WHERE order_id = 999) FOR UPDATE—— 这里order_items行不锁，若该订单正在被修改，子查询可能读到中间态 - 正确做法：确保子查询本身是确定性、只读且无并发变更风险；否则应先查
order_items缓存值，再拼入主 SQL - 若必须关联锁定，得拆成两步：
SELECT qty FROM order_items WHERE order_id = 999 FOR UPDATE（加锁），再查库存
影响行数为 0 不是异常，而是库存不足的正常信号
用 UPDATE ... WHERE (SELECT stock ...) >= #{num} 扣减后，数据库返回影响行数为 0，不代表 SQL 执行失败，而是明确告诉你“库存不够”。业务代码必须主动检查这个返回值，而不是捕获异常来兜底。
- MySQL 用
ROW_COUNT()，PostgreSQL 用pg_affected_rows()，不要依赖executeUpdate()返回的 int 值是否 > 0（JDBC 默认行为） - 别在存储过程中用
IF ROW_COUNT() = 0 THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'stock insufficient'强制抛错——这会让调用方难区分真错误和业务拒绝 - 推荐返回影响行数，由上层决定是重试、降级还是提示用户
索引缺失会让子查询变成全表扫描，性能崩盘
子查询里涉及的字段（尤其是 WHERE 条件中的主键或唯一键）必须有索引。没有索引时，(SELECT stock FROM products WHERE id = 123) 可能触发全表扫描，锁等待加剧，QPS 断崖下跌。
- 检查执行计划：
EXPLAIN看子查询是否走了type=const或ref，而非ALL - 复合条件如
sku_id = ? AND warehouse_id = ?，需建联合索引，顺序按查询条件选择性高低排 - 避免在子查询中用函数或表达式，如
WHERE id = CAST(? AS SIGNED)，会失效索引
子查询嵌套层级、锁范围、返回值约束这些细节，稍不注意就从“防超卖”变成“制造热点”。真正关键的不是语法多漂亮，而是每一行 SQL 能否在高并发下稳定给出确定性结果。
