mysql 库存设计_商品库存“存取设计”，MySQL事务、表锁、行锁

MySQL  使用 SELECT ... FOR UPDATE 做事务写入前的确认

以MySQL 的InnoDB 为例，预设的 Tansaction isolation level 为 REPEATABLE READ，在 SELECT 的读取锁定主要分为两种方式:

SELECT ... LOCK IN SHARE MODE

SELECT ... FOR UPDATE

这两种方式在事务(Transaction) 进行当中SELECT 到同一个数据表时，都必须等待其它事务数据被提交(Commit)后才会执行。而主要的不同在于LOCK IN SHARE MODE 在有一方事务要Update 同一个表单时很容易造成死锁 。

简单的说，如果SELECT 后面若要UPDATE 同一个表单，最好使用 SELECT ... UPDATE。

举个例子：假设商品表单products 内有一个存放商品数量的quantity ，在订单成立之前必须先确定quantity 商品数量是否足够(quantity>0) ，然后才把数量更新为1。

不安全的做法：

1

SELECT quantityFROM productsWHERE id=3;

2

UPDATE productsSET quantity = 1WHERE id=3;

为什么不安全呢？

少量的状况下或许不会有问题，但是大量的数据存取「铁定」会出问题。

如果我们需要在 quantity>0 的情况下才能扣库存，假设程序在第一行 SELECT 读到的 quantity 是 2 ，看起来数字没有错，但是当MySQL 正准备要UPDATE 的时候，可能已经有人把库存扣成 0 了ÿ