库存字段必须用int unsigned，禁用decimal或bigint；主键须按sku粒度设计；update扣减必须带stock>=?条件并校验影响行数，否则必然超卖。
库存字段必须用 INT 且带 UNSIGNED，别用 DECIMAL 或 BIGINT
电商库存本质是整数计数，DECIMAL 带小数点会干扰扣减逻辑（比如误扣 0.5 件），BIGINT 在绝大多数场景纯属冗余——单 SKU 日销百万级已算头部大促，INT UNSIGNED 最大值 4294967295 完全够用。更关键的是，MySQL 的 UPDATE ... SET stock = stock - 1 原子操作依赖整型的精确自减，浮点或高精度类型可能引入隐式转换或锁行为异常。
常见错误：有人为“预留扩展性”选 BIGINT，结果发现二级索引体积翻倍、主从同步延迟升高；还有人用 TINYINT 存“有/无货”状态，导致后续无法支持多件下单。
-
stock字段定义必须是INT UNSIGNED NOT NULL DEFAULT 0 - 禁止加
COMMENT '库存'这类无意义注释，但要加CHECK (stock >= 0)（MySQL 8.0.16+ 支持） - 如果业务需记录“锁定中”的库存（如购物车占位），另建
locked_stock字段，同为INT UNSIGNED
主键和唯一约束要覆盖「商品 + 规格」粒度，别只用商品ID
电商实际售卖单位是 SKU（例如 iPhone 15 256G 蓝色），不是 SPUI（iPhone 15）。如果表结构只以 product_id 为主键，会导致所有规格共用一个库存，一抢光就全下架——这明显违背业务事实。
典型翻车场景：用户下单时传入 sku_id=1001，但库存表里查的是 product_id=100，扣减后其他颜色尺寸还能下单，数据彻底错乱。
- 主键应设为
(sku_id)，或复合主键(product_id, spec_code)（后者需确保spec_code全局唯一） - 必须加唯一索引：
UNIQUE KEY uk_sku_id (sku_id)，防止重复插入 - 禁止用
id BIGINT AUTO_INCREMENT当主键再加业务字段索引——查库存时走不到索引，全表扫描锁表
UPDATE 必须带 WHERE stock >= ? 条件，且返回影响行数判断是否超卖
防超卖的核心不在表结构，而在每次扣减时的原子校验。只靠数据库约束不够：两个并发请求同时读到 stock=1，都执行 UPDATE SET stock = stock - 1，最终变成 -1。必须让数据库在更新前就拒绝掉“不够扣”的请求。
错误写法：UPDATE inventory SET stock = stock - 1 WHERE sku_id = 1001 —— 没校验直接扣，必然超卖。
- 正确 SQL：
UPDATE inventory SET stock = stock - 1 WHERE sku_id = 1001 AND stock >= 1 - 应用层必须检查
mysql_affected_rows()（PHP）或cursor.rowcount（Python）是否等于 1 - 如果返回 0，说明条件不满足（库存不足或已被扣完），立刻抛出业务异常，**不要重试**——重试只会加剧竞争
高并发下要警惕间隙锁导致的死锁，SELECT ... FOR UPDATE 不是万能解
有人试图用先查再锁的方式：SELECT stock FROM inventory WHERE sku_id = 1001 FOR UPDATE，再判断后 UPDATE。这在低并发时可行，但大促时极易触发间隙锁死锁——尤其当 sku_id 是非连续主键（比如 UUID 或雪花 ID），MySQL 会对查询范围加间隙锁，不同事务按不同顺序访问 SKU 就会互相等待。
真实案例：A 事务锁了 sku_id=1001，B 事务锁了 sku_id=1002，然后 A 想更新 1002，B 想更新 1001，死锁爆发。
- 优先用上一条的“条件更新”方案，它只加行锁，不加间隙锁
- 如果必须用
SELECT ... FOR UPDATE（例如要同时扣减多个 SKU），务必按sku_id升序排序后再锁，强制访问顺序一致 - 监控
SHOW ENGINE INNODB STATUS中的deadlock日志，重点看WAITING FOR THIS LOCK TO BE GRANTED行
实际防超卖最脆弱的一环，往往不是表结构设计，而是应用层没校验 UPDATE 影响行数，或者把库存校验逻辑放在缓存层却忘了回写一致性。表结构只是基础，它得扛得住正确的 SQL 写法。
