库存扣减必须用 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 怎么写，而在于你是否清楚每一行锁的生命周期、每一次浮点计算的隐含误差、以及每一条日志在故障时能否成为定责依据。
