不能。MySQL 5.7及更早版本不支持子查询直接用于UPDATE的WHERE条件，会报ERROR 1093；MySQL 8.0+虽语法支持，但子查询无行级锁语义，无法保证并发安全，必须用SELECT ... FOR UPDATE显式加锁并配合事务实现原子性扣减。
子查询能直接用于UPDATE的WHERE条件吗
不能。MySQL 5.7 及更早版本会报错 ERROR 1093: You can't specify target table 't' for update in FROM clause；MySQL 8.0+ 虽支持，但用子查询锁定行本身不提供行级锁语义——它只过滤数据，不阻塞并发修改。
真正需要的是「先查再锁再改」的原子性，而纯子查询（如 UPDATE stock SET qty = qty - 1 WHERE id IN (SELECT id FROM stock WHERE sku = 'A001' AND qty >= 1)）在高并发下必然超扣。
- 子查询执行时快照读（MVCC），不加
FOR UPDATE就不持锁 - 即使加了
FOR UPDATE，若子查询未走索引或范围过大，可能升级为间隙锁甚至表锁 - UPDATE 自身的 WHERE 条件若未命中索引，同样无法精确锁定目标行
必须用SELECT ... FOR UPDATE显式加锁
库存扣减的核心是「读取可用库存 → 判断是否充足 → 扣减 → 返回结果」四步，且中间不能被其他事务干扰。唯一可靠方式是显式使用 SELECT ... FOR UPDATE 在可重复读（RR）隔离级别下获取排他锁。
典型安全写法：
START TRANSACTION; SELECT qty FROM stock WHERE sku = 'A001' AND qty >= 1 ORDER BY id LIMIT 1 FOR UPDATE;
注意点：
-
FOR UPDATE必须在事务中，且后续 UPDATE/DELETE 需作用于同一行（否则锁失效） -
ORDER BY + LIMIT是为了确定唯一目标行；无索引时ORDER BY可能触发 filesort，建议sku和qty组合建索引 - 若查不到结果（
qty < 1），应用层需立即回滚，不能继续执行 UPDATE
UPDATE ... WHERE 加锁条件要和SELECT完全一致
SELECT 锁住的行，UPDATE 必须通过相同索引条件定位到同一行，否则会锁错或漏锁。例如：
✅ 正确（复用索引路径）：
SELECT id, qty FROM stock WHERE sku = 'A001' AND qty >= 1 ORDER BY id LIMIT 1 FOR UPDATE; UPDATE stock SET qty = qty - 1 WHERE id = ?; -- ? 是上一步查出的 id
❌ 危险（条件不一致，可能锁多行或跳过已锁行）：
UPDATE stock SET qty = qty - 1 WHERE sku = 'A001' AND qty >= 1; -- 没有 id 约束，可能锁住多行或触发新扫描
- WHERE 中用
id（主键）更新，确保只影响一行、且走聚簇索引，锁粒度最小 - 避免在 UPDATE 的 WHERE 中重复判断
qty >= 1：该检查已在 SELECT 阶段完成，重复判断不仅冗余，还可能导致幻读（比如 SELECT 后另一事务插入新行并满足条件） - UPDATE 后务必检查
ROW_COUNT()是否为 1，防止因网络重试或逻辑错误导致重复执行
为什么不能依赖触发器或存储过程封装扣减逻辑
看似封装后调用简单，但实际掩盖了事务边界和锁行为。例如一个「扣减函数」内部做 SELECT + UPDATE，若调用方没开启事务，锁会在函数结束时释放，失去原子性。
更隐蔽的问题：
- 存储过程中无法返回「查无可用库存」这种业务信号给应用层，只能抛错，难以区分是库存不足还是死锁
- 触发器无法控制调用上下文，UPDATE stock SET qty = qty - 1 触发后，原 SQL 的 WHERE 条件已不可控
- 跨分库分表场景下，存储过程无法迁移，而显式 SELECT+UPDATE 更容易适配 ShardingSphere 或自研路由逻辑
真正复杂的库存逻辑（如按优先级选仓、预留+确认两阶段、库存分片）必须由应用层控制事务生命周期和分支判断，数据库只负责精准加锁与原子更新。
