扣库存必须用事务包裹，否则一定丢数据；单条update无法保证“查-判-减”完整性，需用select...for update加锁后应用层校验，配合事务和索引保障原子性与行级锁有效性。
扣库存必须用事务包裹，否则一定丢数据
单条 UPDATE 语句看似原子，但在高并发下无法保证“查-判-减”逻辑的完整性。比如先 SELECT stock FROM product_stock WHERE product_id = 1001，再 UPDATE ... SET stock = stock - 1，中间可能被其他事务插入或修改，导致超卖。必须把库存校验、扣减、订单生成三步放在同一个事务里，靠 ACID 保障整体原子性。
事务开启方式取决于应用层配置：
– Spring Boot 中默认 @Transactional 即开启；
– 原生 JDBC 需显式调用 conn.setAutoCommit(false)；
– MyBatis 需确认 spring.datasource.hikari.auto-commit=false 或由框架代理控制。
关键点：
– 不要依赖 autocommit=1 下的单条 UPDATE；
– 事务边界必须包含所有相关操作（如扣库存 + 插订单）；
– 若事务内混用 DML 和 DDL（如 ALTER TABLE），会隐式提交，破坏原子性。
WHERE 条件必须命中索引，否则行锁变表锁
这是线上死锁和性能雪崩最常见原因。InnoDB 的行级锁只在 WHERE 条件能走索引时生效；一旦 product_id 字段没建索引，或查询用了函数（如 WHERE CAST(product_id AS CHAR) = '1001'），就会退化为表级锁，所有扣库存请求排队阻塞。
检查方法：
– 执行 EXPLAIN SELECT * FROM product_stock WHERE product_id = 1001 FOR UPDATE，确认 type 是 const 或 ref，且 key 显示实际使用的索引；
– 确保 product_id 是主键或有唯一索引；
– 避免在 WHERE 中对字段做运算、类型转换、函数包装。
典型错误：
– WHERE CONCAT('P', product_id) = 'P1001' → 无法走索引；
– WHERE product_id = ? 但传入的是字符串类型参数，而字段是 BIGINT → 隐式转换失效；
– 使用 LIKE '%1001' → 全表扫描 + 表锁。
用 SELECT ... FOR UPDATE 而不是 UPDATE ... WHERE stock > 0
仅靠 UPDATE product_stock SET stock = stock - 1 WHERE product_id = 1001 AND stock > 0 无法完全防超卖。因为多个事务同时执行该语句时，可能都读到 stock=1，都满足 stock > 0，最终扣成 -1。
正确做法是先加锁再判断：
– SELECT stock FROM product_stock WHERE product_id = 1001 FOR UPDATE；
– 应用层判断返回值是否 ≥1；
– 满足则执行 UPDATE，不满足则直接回滚。
为什么更安全：
– FOR UPDATE 是当前读，触发 Next-Key Lock（行锁 + 间隙锁），阻塞其他事务对该记录的任何并发修改；
– 即使两个事务几乎同时执行 SELECT ... FOR UPDATE，第二个会被挂起，等第一个释放锁后才继续，天然串行化；
– 配合事务，可确保“查库存→扣减→下单”整条链路不被干扰。
注意：
– 不要用 LOCK IN SHARE MODE，它允许多个事务同时读，无法阻止并发扣减；
– MySQL 8.0+ 推荐用 FOR UPDATE，语义清晰，兼容性好；
– 锁必须在事务内获取，否则 COMMIT 后立即释放，失去意义。
死锁不是异常，是并发设计缺陷的信号
出现 Deadlock found when trying to get lock 不代表代码写错了，而是事务访问资源的顺序不一致。比如事务 A 先锁 product_id = 1001 再锁 user_id = 123，事务 B 反过来，就容易形成环路。
规避方法：
– 所有业务路径按固定顺序访问表和行（例如总是先锁商品，再锁用户，再锁订单）；
– 尽量缩短事务时间，避免在事务内做 RPC、文件 IO、复杂计算；
– 减少锁持有范围：不要 SELECT * FROM ... FOR UPDATE，只查必要字段；
– 利用 SHOW ENGINE INNODB STATUS 定位死锁日志，看哪两行 SQL 在争抢同一资源。
真实陷阱：
– 分页查询中用 ORDER BY create_time LIMIT 10 加 FOR UPDATE，可能锁住大量无关记录（间隙锁放大）；
– 同一事务里多次更新同一行（如循环扣减），会累积锁等待；
– 应用层重试逻辑没设上限，导致死锁重试雪球效应。
