库存扣减必须用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、允许的延迟和运维能力。
历史库存变更必须单独建表，别挤在主表里
有人习惯在 items 表加 last_update_time 和 update_reason 字段记录每次变动，这会导致：
- 主表体积膨胀快，影响所有
SELECT *查询性能 - 无法回溯完整操作链（谁、何时、为什么、从多少变成多少）
- 审计合规时拿不出不可篡改的操作日志
正确做法是建独立表 item_stock_logs，至少包含：item_id、before_stock、after_stock、change_amount、operator_id、reason、created_at。用触发器或应用层显式插入，确保每次 UPDATE items 都有对应日志。注意给 item_id 和 created_at 建联合索引，方便按商品查变更历史。
库存系统真正的难点不在 SQL 怎么写，而在于你是否清楚每一行锁的生命周期、每一次浮点计算的隐含误差、以及每一条日志在故障时能否成为定责依据。
