分析Mysql事务和数据的一致性处理问题

这篇文章通过安全性，用法，并发处理等方便详细分析了Mysql事务和数据的一致性处理问题，以下就是全部内容：

在工作中，我们经常会遇到这样的问题，需要更新库存，当我们查询到可用的库存准备修改时，这时，其他的用户可能已经对这个库存数据进行修改了，导致，我们查询到的数据会有问题，下面我们就来看解决方法。

在MySQL的InnoDB中，预设的Tansaction isolation level 为REPEATABLE READ（可重读）

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

举个例子:

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

为什么不安全呢?

少量的状况下或许不会有问题，但是大量的数据存取「铁定」会出问题。如果我们需要在quantity>0 的情况下才能扣库存，假设程序在第一行SELECT 读到的quantity 是2 ，看起来数字没有错，但是当MySQL 正准备要UPDATE 的时候，可能已经有人把库存扣成0 了，但是程序却浑然不知，将错就错的UPDATE 下去了。因此必须透过的事务机制来确保读取及提交的数据都是正确的。

于是我们在MySQL 就可以这样测试，代码如下:

此时products 数据中id=3 的数据被锁住(注3)，其它事务必须等待此次事务 提交后才能执行

如此可以确保quantity 在别的事务读到的数字是正确的。

提交(Commit)写入数据库，products 解锁。

注1: BEGIN/COMMIT 为事务的起始及结束点，可使用二个以上的MySQL Command 视窗来交互观察锁定的状况。

注2: 在事务进行当中，只有SELECT ... FOR UPDATE 或LOCK IN SHARE MODE 同一笔数据时会等待其它事务结束后才执行，一般SELECT ... 则不受此影响。

注3: 由于InnoDB 预设为Row-level Lock，数据列的锁定可参考这篇。

注4: InnoDB 表单尽量不要使用LOCK TABLES 指令，若情非得已要使用，请先看官方对于InnoDB 使用LOCK TABLES 的说明，以免造成系统经常发生死锁。

更高级用法

如果我们需要先查询，后更新数据的话，最好可以这样使用语句：

这样，可以不用添加事物就可处理。