共计 4850 个字符，预计需要花费 13 分钟才能阅读完成。
这篇文章主要介绍 Mysql 事务及数据一致性处理的示例分析，文中介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们一定要看完！
在 MySQL 的 InnoDB 中，预设的 Tansaction isolation level 为 REPEATABLE READ（可重读）
如果 SELECT 后面若要 UPDATE 同一个表单，最好使用 SELECT … UPDATE。
举个例子:
假设商品表单 products 内有一个存放商品数量的 quantity，在订单成立之前必须先确定 quantity 商品数量是否足够(quantity 0)，然后才把数量更新为 1。代码如下:
SELECT quantity FROM products WHERE id=3; UPDATE products SET quantity = 1 WHERE id=3;为什么不安全呢?
少量的状况下或许不会有问题，但是大量的数据存取「铁定」会出问题。如果我们需要在 quantity 0 的情况下才能扣库存，假设程序在第一行 SELECT 读到的 quantity 是 2，看起来数字没有错，但是当 MySQL 正准备要 UPDATE 的时候，可能已经有人把库存扣成 0 了，但是程序却浑然不知，将错就错的 UPDATE 下去了。因此必须透过的事务机制来确保读取及提交的数据都是正确的。
于是我们在 MySQL 就可以这样测试，代码如下:
SET AUTOCOMMIT=0; BEGIN WORK; SELECT quantity FROM products WHERE id=3 FOR UPDATE;此时 products 数据中 id=3 的数据被锁住(注 3)，其它事务必须等待此次事务 提交后才能执行
SELECT * FROM products WHERE id=3 FOR UPDATE如此可以确保 quantity 在别的事务读到的数字是正确的。
UPDATE products SET quantity = 1 WHERE id=3 ; COMMIT WORK;提交 (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 的说明，以免造成系统经常发生死锁。
更高级用法
如果我们需要先查询，后更新数据的话，最好可以这样使用语句：
UPDATE products SET quantity = 1 WHERE id=3 AND quantity 0;这样，可以不用添加事物就可处理。
mysql 处理高并发，防止库存超卖
看到了一篇非常好的文章，特转此学习。
今天王总又给我们上了一课，其实 mysql 处理高并发，防止库存超卖的问题，在去年的时候，王总已经提过；但是很可惜，即使当时大家都听懂了，但是在现实开发中，还是没这方面的意识。今天就我的一些理解，整理一下这个问题，并希望以后这样的课程能多点。
先来就库存超卖的问题作描述：一般电子商务网站都会遇到如团购、秒杀、特价之类的活动，而这样的活动有一个共同的特点就是访问量激增、上千甚至上万人抢购一个商品。然而，作为活动商品，库存肯定是很有限的，如何控制库存不让出现超买，以防止造成不必要的损失是众多电子商务网站程序员头疼的问题，这同时也是最基本的问题。
从技术方面剖析，很多人肯定会想到事务，但是事务是控制库存超卖的必要条件，但不是充分必要条件。
举例：
总库存：4 个商品
请求人：a、1 个商品 b、2 个商品 c、3 个商品
程序如下：
beginTranse(开启事务)
$result = $dbca- query( select amount from s_store where postID = 12345
if(result- amount 0){
//quantity 为请求减掉的库存数量
$dbca- query( update s_store set amount = amount - quantity where postID = 12345
}
}catch($e Exception){ rollBack(回滚)
commit(提交事务)以上代码就是我们平时控制库存写的代码了，大多数人都会这么写，看似问题不大，其实隐藏着巨大的漏洞。数据库的访问其实就是对磁盘文件的访问，数据库中的表其实就是保存在磁盘上的一个个文件，甚至一个文件包含了多张表。例如由于高并发，当前有三个用户 a、b、c 三个用户进入到了这个事务中，这个时候会产生一个共享锁，所以在 select 的时候，这三个用户查到的库存数量都是 4 个，同时还要注意，mysql innodb 查到的结果是有版本控制的，再其他用户更新没有 commit 之前(也就是没有产生新版本之前)，当前用户查到的结果依然是就版本；
然后是 update，假如这三个用户同时到达 update 这里，这个时候 update 更新语句会把并发串行化，也就是给同时到达这里的是三个用户排个序，一个一个执行，并生成排他锁，在当前这个 update 语句 commit 之前，其他用户等待执行，commit 后，生成新的版本；这样执行完后，库存肯定为负数了。但是根据以上描述，我们修改一下代码就不会出现超买现象了，代码如下：
beginTranse(开启事务)
//quantity 为请求减掉的库存数量
$dbca- query( update s_store set amount = amount - quantity where postID = 12345
$result = $dbca- query( select amount from s_store where postID = 12345
if(result- amount 0){
throw new Exception( 库存不足
}
}catch($e Exception){ rollBack(回滚)
commit(提交事务)另外，更简洁的方法：
beginTranse(开启事务)
//quantity 为请求减掉的库存数量
$dbca- query(update s_store set amount = amount - quantity where amount =quantity and postID = 12345}catch($e Exception){ rollBack(回滚)
commit(提交事务)=====================================================================================
1、在秒杀的情况下，肯定不能如此高频率的去读写数据库，会严重造成性能问题的
必须使用缓存，将需要秒杀的商品放入缓存中，并使用锁来处理其并发情况。当接到用户秒杀提交订单的情况下，先将商品数量递减（加锁 / 解锁）后再进行其他方面的处理，处理失败在将数据递增 1（加锁 / 解锁），否则表示交易成功。
当商品数量递减到 0 时，表示商品秒杀完毕，拒绝其他用户的请求。
2、这个肯定不能直接操作数据库的，会挂的。直接读库写库对数据库压力太大，要用缓存。
把你要卖出的商品比如 10 个商品放到缓存中；然后在 memcache 里设置一个计数器来记录请求数，这个请求书你可以以你要秒杀卖出的商品数为基数，比如你想卖出 10 个商品，只允许 100 个请求进来。那当计数器达到 100 的时候，后面进来的就显示秒杀结束，这样可以减轻你的服务器的压力。然后根据这 100 个请求，先付款的先得后付款的提示商品以秒杀完。
3、首先，多用户并发修改同一条记录时，肯定是后提交的用户将覆盖掉前者提交的结果了。
这个直接可以使用加锁机制去解决，乐观锁或者悲观锁。
乐观锁:，就是在数据库设计一个版本号的字段，每次修改都使其 +1，这样在提交时比对提交前的版本号就知道是不是并发提交了，但是有个缺点就是只能是应用中控制，如果有跨应用修改同一条数据乐观锁就没办法了，这个时候可以考虑悲观锁。
悲观锁:，就是直接在数据库层面将数据锁死，类似于 oralce 中使用 select xxxxx from xxxx where xx=xx for update，这样其他线程将无法提交数据。
除了加锁的方式也可以使用接收锁定的方式，思路是在数据库中设计一个状态标识位，用户在对数据进行修改前，将状态标识位标识为正在编辑的状态，这样其他用户要编辑此条记录时系统将发现有其他用户正在编辑，则拒绝其编辑的请求，类似于你在操作系统中某文件正在执行，然后你要修改该文件时，系统会提醒你该文件不可编辑或删除。
4、不建议在数据库层面加锁，建议通过服务端的内存锁（锁主键）。当某个用户要修改某个 id 的数据时，把要修改的 id 存入 memcache，若其他用户触发修改此 id 的数据时，读到 memcache 有这个 id 的值时，就阻止那个用户修改。
5、实际应用中，并不是让 mysql 去直面大并发读写，会借助“外力”，比如缓存、利用主从库实现读写分离、分表、使用队列写入等方法来降低并发读写。
悲观锁和乐观锁
首先，多用户并发修改同一条记录时，肯定是后提交的用户将覆盖掉前者提交的结果了。这个直接可以使用加锁机制去解决，乐观锁或者悲观锁。
悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会 block 直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。
乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库如果提供类似于 write_condition 机制的其实都是提供的乐观锁。
两种锁各有优缺点，不能单纯的定义哪个好于哪个。乐观锁比较适合数据修改比较少，读取比较频繁的场景，即使出现了少量的冲突，这样也省去了大量的锁的开销，故而提高了系统的吞吐量。但是如果经常发生冲突（写数据比较多的情况下），上层应用不不断的 retry，这样反而降低了性能，对于这种情况使用悲观锁就更合适。
实战
对这个表的 amount 进行修改，开两个命令行窗口
第一个窗口 A;
SET AUTOCOMMIT=0; BEGIN WORK; SELECT * FROM order_tbl WHERE order_id= 124 FOR UPDATE;第二个窗口 B：
# 更新订单 ID 124 的库存数量
UPDATE `order_tbl` SET amount = 1 WHERE order_id = 124;我们可以看到窗口 A 加了事物，锁住了这条数据，窗口 B 执行时会出现这样的问题：
第一个窗口完整的提交事物：
SET AUTOCOMMIT=0; BEGIN WORK; SELECT * FROM order_tbl WHERE order_id= 124 FOR UPDATE;
UPDATE `order_tbl` SET amount = 10 WHERE order_id = 124;
COMMIT WORK;以上是“Mysql 事务及数据一致性处理的示例分析”这篇文章的所有内容，感谢各位的阅读！希望分享的内容对大家有帮助，更多相关知识，欢迎关注丸趣 TV 行业资讯频道！
