用 UPDATE ... WHERE stock > 0 做减库存，但必须加唯一索引防超卖
高并发秒杀最常踩的坑是：只写 SELECT stock FROM goods WHERE id = 1 再判断是否大于 0，然后 UPDATE —— 这中间有竞态窗口，N 个请求查到都是 10，全会执行更新，直接超卖。
正确做法是把“检查 + 扣减”合并成一条原子语句：UPDATE goods SET stock = stock - 1 WHERE id = 1 AND stock > 0。MySQL 的行锁会锁住这一行，后续请求必须等前一个事务提交后才能读到最新 stock 值。
- 务必给
id字段建主键（默认已有），否则可能升级为表锁 - 如果业务允许“预占库存”，可额外加一列
locked_stock，用乐观锁或 Redis 分布式锁前置拦截，减少数据库压力 - 执行后立刻检查
ROW_COUNT()返回值：等于 0 表示库存不足或已被抢完，不是 SQL 报错
为什么不能用 INSERT ... ON DUPLICATE KEY UPDATE 实现秒杀订单去重
有人想靠唯一订单号 + ON DUPLICATE KEY UPDATE 来避免重复下单，逻辑看似可行，但实际在高并发下会因间隙锁（gap lock）引发大量死锁，尤其当订单号是时间戳+随机数这类非严格递增字段时。
根本问题在于：InnoDB 对 INSERT 的唯一约束检查会锁定索引区间，多个线程同时插入相似订单号（比如毫秒级时间前缀），极易触发间隙锁冲突。
- 真正安全的幂等下单，应该先用
SELECT ... FOR UPDATE锁住商品行，再插入订单，最后更新库存 —— 顺序不能反 - 如果用订单号做唯一键，建议用雪花 ID 或 UUIDv7，避免时间局部性带来的间隙锁争抢
-
INSERT IGNORE虽不报错，但无法区分“插入成功”和“因重复被忽略”，业务层拿不到准确结果
stock 字段必须是 INT 且带符号，别用 UNSIGNED
用 UNSIGNED INT 存库存，看起来更“安全”，但一旦扣成负数，MySQL 不会报错，而是变成极大正数（比如 4294967295），后续所有 WHERE stock > 0 都成立，彻底失控。
而有符号 INT 在 stock = 0 时执行 stock = stock - 1，结果是 -1，WHERE stock > 0 自动失效，天然阻止超卖。
- 别依赖应用层校验“不能小于 0”，数据库才是最后一道防线
- 如果真需要记录超扣行为（比如风控审计），可用触发器或应用层捕获
ROW_COUNT() == 0后写日志，而不是让字段溢出 - ALTER TABLE 改字段类型时，
UNSIGNED到SIGNED是锁表操作，线上慎用
减库存 SQL 的性能瓶颈不在语句本身，而在事务持续时间和锁范围
单条 UPDATE 很快，但如果你在事务里还做了查用户余额、写日志、调外部接口，那这行记录就被锁住几十毫秒甚至更久，QPS 直接腰斩。
秒杀场景下，数据库要扛住的是“短平快”的原子操作，不是复杂业务流程。
- 把减库存作为独立事务执行，完成后立即
COMMIT，其他逻辑（如生成订单、发消息）异步走 MQ - 避免在减库存事务里
JOIN多张表或查大字段，哪怕只是SELECT name也会延长锁持有时间 - 监控
Innodb_row_lock_time_avg和Threads_running，这两个指标突增，基本就是锁成了瓶颈
真正难的不是写出那条 SQL，而是让这条 SQL 在 5ms 内完成，并且不拖垮整个库。锁粒度、事务边界、异步拆分，这些比语法细节重要得多。
