mysql 超卖_mysql 解决超卖问题的锁分析

解决超卖问题，常见的方式，利用redis 的原子性去递减；利用队列，队列入队计数。或者直接打到mysql 层。由mysql 保证不超卖，有几个玩法。利用属性不一样，挺有意思，记录下。

首先，mysql 隔离级别是RR，或者是串行，但是不可能用串行，太慢。

其次，为什么会出现超卖问题？因为这个select and update 是个非原子操作，是两步操作。

最后，怎么解决这个问题? 就在原子性上做文章，比如redis 的 lua 封装，将指令封装成原子操作。或者mysql 的互斥锁，再或者，干脆允许超卖，业务层做二次检查。

第一种，mysql 在select 的时候不加互斥锁，这个时候的做法：

1：开启事务

2：查询库存，并显示的设置写锁(排他锁)：SELECT * FROM table_name WHERE …

3：生成订单

4：去库存，隐示的设置写锁(排他锁)：UPDATE goods SET counts = counts – 1 WHERE id = 1

5：commit，释放锁

这里提下mysql 的RC 和RR 区别，mysql 是如何实现可重复读的？ RR隔离级别是在事务开始时刻，确切地说是第一个读操作创建read view的；RC隔离级别是在语句开始时刻创建read view的。一个read view 可以理解成一份快照(底层只是事务id 列表)，所以，RC 隔离级别下，多次读可能受其他事务commit 导致读取数据不一致。

那么 RR 级别下，select 和 update 的时候， 数据是一个version的，但是上面做法的问题，就在于，几个事务begin 后，都读到数据为1，就开始 update ，就会导致数据最终为负数，这种方式，避不了为负数。

我们可以做个二次容错，检查update 后数据为负数后，直接回滚这次事务即可。

第二种方式是select 的时候就加行锁，select for update ，直接锁住这条记录，不让其他事务读。所以对这个数据，都成串行，这个缺点就是会影响性能，但是不会出现超卖的情况了。

1：开启事务

2：查询库存，并显示的设置写锁(排他锁)：SELECT * FROM table_name WHERE … FOR UPDATE

3：生成订单

4：去库存，隐示的设置写锁(排他锁)：UPDATE goods SET counts = counts – 1 WHERE id = 1

5：commit，释放锁。

第三种，试着给select 加读锁，这种做法是不行，会出现死锁，什么情况会死锁呢？事务1，2同时加读锁，事务1加写锁等事务2的写锁，事务2的加写锁等事务1的读锁，相互等待，陷入死锁。那为啥 select for update 不会这样，因为mysql 互斥锁是可重入锁啊。