超卖问题多出现在高并发的库存扣减场景，比如电商平台的秒杀活动，多个用户同时下单时，如果没有合适的并发控制机制，就可能出现库存被多次扣减为负数的情况。MySQL的悲观锁结合Select For Update和事务，是解决这个问题常用的方案之一。
超卖问题的产生原因
我们先来看一个典型的超卖场景，假设商品当前库存为1，两个用户同时发起下单请求，两个请求同时查询到库存为1，都认为可以下单，随后都执行库存减1的操作，最终库存会变成-1，这就是超卖。
出现这个问题的核心原因是查询库存和扣减库存两个操作不是原子的，在并发场景下会产生竞态条件。要解决这个问题，就需要保证这两个操作的原子性，悲观锁就是实现这个目标的一种方式。
悲观锁与Select For Update原理
悲观锁的核心思想是假设并发冲突发生的概率很高，所以在操作数据之前就先对数据加锁，其他事务如果要操作同一数据就需要等待锁释放。
MySQL中InnoDB引擎支持行级锁，Select For Update语句可以对查询到的行加排他锁，在事务提交之前，其他事务无法对这些行执行更新、删除操作，也无法执行Select For Update查询，从而保证当前事务操作这些数据时不会被其他事务干扰。
配合事务实现超卖解决方案
使用Select For Update解决超卖问题，必须配合事务使用，因为锁的释放是在事务提交或者回滚的时候。下面是具体的实现步骤和代码示例。
1. 数据库表结构
我们设计一个简单的商品库存表，结构如下：
CREATE TABLE `product_stock` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`product_name` varchar(50) NOT NULL COMMENT '商品名称',
`stock` int(11) NOT NULL COMMENT '商品库存',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='商品库存表';
-- 插入测试数据，库存为10
INSERT INTO `product_stock` (`product_name`, `stock`) VALUES ('测试商品', 10);
2. 核心实现逻辑
整个扣减库存的流程需要放在一个事务中，步骤如下：
- 开启事务
- 使用
Select For Update查询目标商品的库存，此时会对该行加排他锁 - 判断库存是否大于等于购买数量，如果不足则回滚事务
- 如果库存充足，执行库存扣减操作
- 提交事务，释放锁
3. Java代码示例
下面是使用Spring Boot + MyBatis实现的示例代码：
@Service
public class ProductStockService {
@Autowired
private ProductStockMapper productStockMapper;
@Transactional(rollbackFor = Exception.class)
public boolean deductStock(Integer productId, Integer buyNum) {
// 1. 加锁查询库存，Select For Update会加行排他锁
ProductStock stock = productStockMapper.selectStockForUpdate(productId);
if (stock == null) {
throw new RuntimeException("商品不存在");
}
// 2. 判断库存是否充足
if (stock.getStock() < buyNum) {
throw new RuntimeException("库存不足");
}
// 3. 扣减库存
int updateCount = productStockMapper.deductStock(productId, buyNum);
return updateCount > 0;
}
}
对应的Mapper接口和XML配置：
public interface ProductStockMapper {
ProductStock selectStockForUpdate(Integer productId);
int deductStock(Integer productId, Integer buyNum);
}
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://ipipp.com/dtd/mybatis-3-mapper.dtd">
<mapper namespace="com.example.mapper.ProductStockMapper">
<select id="selectStockForUpdate" resultType="com.example.entity.ProductStock">
SELECT id, product_name, stock FROM product_stock WHERE id = #{productId} FOR UPDATE
</select>
<update id="deductStock">
UPDATE product_stock SET stock = stock - #{buyNum} WHERE id = #{productId}
</update>
</mapper>
注意事项
Select For Update只有在查询条件命中索引时才会加行锁，如果没有命中索引会升级为表锁，严重影响并发性能，所以要确保查询条件有合适的索引。- 事务要尽量小，避免长时间持有锁，减少阻塞其他事务的时间。
- 这种方案适合并发量不是特别高的场景，如果并发量极高，行锁的竞争会比较激烈，可能需要结合其他方案比如Redis分布式锁来优化。
- 如果查询的时候没有找到对应的行，不会加锁，所以要先判断查询结果是否为空。
方案优缺点分析
我们可以通过下面的表格对比这种方案的优缺点：
| 优点 | 缺点 |
|---|---|
| 实现简单，不需要引入额外的组件，依赖MySQL自身的能力即可实现 | 并发量高时锁竞争严重，性能会下降 |
| 数据一致性有保障，基于数据库ACID特性，不会出现数据不一致问题 | 只能解决单数据库实例的并发问题，分库分表场景不适用 |
| 不需要额外的分布式锁组件，降低系统复杂度 | 事务持有锁的时间如果过长，会影响其他业务的正常执行 |
MySQL悲观锁Select_For_Update超卖问题事务修改时间：2026-07-15 15:54:28