库存扣减必须用UPDATE…WHERE stock>=?加行锁，禁止先SELECT再UPDATE以防超卖；stock须用INT UNSIGNED类型；高并发时可分片、异步或缓存兜底；历史变更须单独建log表记录。
库存扣减必须用 UPDATE ... WHERE stock >= ? 加行锁
直接 SELECT 后再 UPDATE 会引发超卖，这是最常见也最危险的错误。MySQL 的 UPDATE 语句在有索引的 WHERE 条件下会自动加行级写锁，且锁住的是“满足条件的记录”，不是“查到的记录”。所以必须把库存校验塞进 WHERE 子句：
UPDATE items SET stock = stock - 1 WHERE id = 123 AND stock >= 1;
执行后检查 ROW_COUNT() 返回值：0 表示库存不足或记录不存在，非 0 才代表扣减成功。别依赖 SELECT 结果做判断——中间可能已被其他事务改过。
stock 字段必须是 INT 或 BIGINT，禁止用 FLOAT/DECIMAL
库存是离散计数，不是度量值。用 DECIMAL(10,2) 看似能支持“0.5 件”，但实际业务中几乎不会出现，反而引入精度误差和比较陷阱（比如 0.3 + 0.6 != 0.9）。更关键的是：FLOAT/DECIMAL 类型无法高效使用 B+ 树索引做范围判断（如 WHERE stock >= 1），会导致全表扫描风险。生产环境一律用 INT UNSIGNED，配合应用层控制最小单位（如“以个为单位”，不存“箱”“托”等复合单位）。
高并发场景下避免单条 UPDATE 成为瓶颈
当秒杀类请求集中打到同一商品时，所有事务都会争抢同一行锁，造成严重排队。可行解法包括：
- 提前分片：按商品 ID 哈希拆成多行（如
stock_shard_0~stock_shard_7），扣减时随机选一个分片操作，最后用SUM()汇总，适合读多写少场景 - 异步化：写入扣减请求到消息队列，由消费者串行更新数据库，用状态机控制“待扣减→已扣减→失败”流转
- 缓存兜底：用 Redis 的
DECR预扣，DB 仅做最终一致性校验与落库，但需处理 Redis 故障时的降级逻辑
没有银弹——分片增加查询复杂度，异步带来延迟，缓存引入双写一致性难题。选哪种取决于你的 QPS、允许的延迟和运维能力。
