MySQL解决超卖的核心是保证库存操作原子性：首选UPDATE带WHERE条件（如stock>=1）直接扣减并检查影响行数；次选SELECT...FOR UPDATE加行锁；辅以数据库约束（如CHECK、UNSIGNED）兜底，并避免长事务与锁竞争。
超卖问题本质是多个并发请求同时读取同一库存值、判断有货、然后扣减，导致实际扣减次数超过剩余库存。MySQL 中解决的关键在于：让“读库存→判断→扣减”这个过程具备原子性，不能被其他事务打断。
用 SELECT ... FOR UPDATE 加行锁
在事务中对库存记录加写锁，确保同一时间只有一个事务能操作该商品库存。
- 开启事务：red">BEGIN
- 查库存并加锁：SELECT stock FROM goods WHERE id = 123 FOR UPDATE（必须走主键或唯一索引，否则可能升级为表锁）
- 应用层判断：if (stock > 0) { 执行 UPDATE ... SET stock = stock - 1 }
- 提交或回滚事务：COMMIT 或 ROLLBACK
注意：FOR UPDATE 必须在事务内使用，且后续必须有 UPDATE/DELETE 等写操作才真正生效；若只查不改，锁会在 COMMIT 后释放，但已避免中间被其他事务修改。
用 UPDATE 带条件原子扣减
跳过显式查询，直接用一条 UPDATE 语句完成“判断+扣减”，依赖 MySQL 的行级更新原子性。
- 执行：UPDATE goods SET stock = stock - 1 WHERE id = 123 AND stock >= 1
- 检查影响行数：if (affected_rows == 1) { 扣减成功 } else { 库存不足，超卖拦截 }
这种方式无需手动加锁、无死锁风险、性能更高，是最推荐的方案。但要注意 WHERE 条件必须包含库存判断逻辑，且 stock 字段要有合理约束（如非负）。
结合数据库约束做兜底
仅靠应用逻辑容易遗漏边界，应在数据库层加固。
- 给 stock 字段加 CHECK (stock >= 0)（MySQL 8.0.16+ 支持）
- 或用触发器在 UPDATE 前校验，非法值直接报错
- 设置 stock 为 UNSIGNED INT，防止出现负数（但无法阻止 0→-1 的越界更新，需配合 WHERE 条件）
约束不是替代并发控制的手段，而是防止因程序 bug 或绕过逻辑导致数据异常的最后一道防线。
避免长事务和锁竞争
锁持有时间越长，系统并发能力越低，还可能引发死锁。
- 把非数据库操作（如调用支付接口、发消息）移到事务外
- SELECT FOR UPDATE 后不要做耗时计算或远程调用
- 库存表尽量拆分，按商品类目或哈希分库分表，降低单行热点
- 高并发场景下可考虑引入 Redis 预减库存（先扣缓存再落库），但需处理缓存与 DB 不一致问题
不复杂但容易忽略：锁粒度要准、事务要短、判断要落在 SQL 层。
