是原子的；InnoDB通过行级排他锁和单条UPDATE语句保障“读-判-改”原子执行，WHERE stock >= ? 确保扣减前校验余量，避免超卖，无需额外事务包裹。
用 UPDATE ... SET stock = stock - ? WHERE id = ? AND stock >= ? 实现原子扣减
MySQL 的 InnoDB 引擎在行级锁 + 条件 WHERE 下天然支持原子性库存扣减，不需要额外事务包裹（单条语句本身已隔离）。关键在于把库存校验和更新合并进同一个 UPDATE 语句，靠数据库自身保证“读-判-改”不被并发打断。
常见错误是先 SELECT stock 再判断再 UPDATE，这中间存在竞态窗口——两个请求可能同时读到足够库存，然后都执行扣减，导致超卖。
-
stock >= ?中的?是你要扣减前要求的最小剩余量（通常是扣减数量本身，比如要扣 1，则写stock >= 1） - 必须给
id字段建索引（最好是主键或唯一索引），否则会升级为表锁或锁范围过大 - 语句执行后检查
ROW_COUNT()：返回 0 表示扣减失败（库存不足或记录不存在），非 0 才代表成功
为什么不能只依赖 WHERE stock > 0
表面看 WHERE stock > 0 也能防止负库存，但它无法阻止“刚好归零后又被扣”的并发问题。例如当前 stock = 1，两个并发请求同时满足 stock > 0，都执行 stock = stock - 1，最终变成 -1。
真正安全的是显式比较“扣完后是否仍 ≥ 0”，即 WHERE stock >= ?，其中 ? 是本次要扣的数量。这个条件在加锁时就被评估，InnoDB 会对满足该条件的行加 X 锁，后续请求必须等待。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 错例：
UPDATE goods SET stock = stock - 1 WHERE id = 123 AND stock > 0→ 可能写入 -1 - 正例：
UPDATE goods SET stock = stock - 1 WHERE id = 123 AND stock >= 1→ 成功则 stock = 0，失败则一行不改 - 如果扣 3 件，条件就得是
stock >= 3，不能硬编码
配合应用层处理返回值与重试逻辑
SQL 层只负责“要么成功扣减，要么完全不改”，但业务需要知道结果并做响应。不要在 SQL 里塞存储过程或触发器来兜底，复杂逻辑应放在应用中。
- 执行后立刻调用数据库驱动的
getRowCount()或等价 API（如 Python 的cursor.rowcount、Java 的executeUpdate()返回值） - 若返回 0，说明库存不足，可直接返回 “库存不足” 或进入异步队列/降级流程
- 极少场景需乐观重试（比如秒杀），但重试间隔必须带随机抖动，避免重试风暴；不建议无限循环重试
- 注意：
ROW_COUNT()在 MySQL 8.0+ 默认行为一致，但某些旧客户端或连接池配置可能影响其准确性，建议显式测试
高并发下要注意隐式锁升级与死锁风险
即使语句本身正确，当多个线程频繁操作同一商品（尤其是热点商品 ID 集中）时，InnoDB 可能因锁等待队列过长而触发锁升级，或因加锁顺序不一致引发死锁。
- 确保
WHERE id = ?走的是聚簇索引（即主键），避免全表扫描导致锁住过多行 - 避免在事务中先更新 A 商品再更新 B 商品，又在另一处反过来操作——这容易形成环路死锁
- 监控
SHOW ENGINE INNODB STATUS中的LATEST DETECTED DEADLOCK段，定位冲突模式 - 对超热门商品，可考虑分桶（如
stock_shard字段）或引入缓存预占（Redis + 最终一致性补偿）分流压力
实际扣减逻辑最脆弱的地方不在 SQL 写法，而在于应用没检查 ROW_COUNT() 就默认成功，或者把库存字段设为 INT 却不做负数拦截——后者会让数据库默默写入负值，直到业务对账才发现。
