MySQL 5.6 , InnoDB存储引擎,默认事务隔离级别(REPEATABLE-READ)
初始sql 脚本如下:
CREATE DEFINER=`root`@`localhost` PROCEDURE `Test`(out debitb decimal(14,2))
BEGIN
START TRANSACTION ;
select @db:=debit_balance from c_account_customer where id=1 ;
set debitb=@db;
insert into abacus.testvalue (val) values (@db);
update abacus.c_account_customer set debit_balance=@db+1 where id=1;
commit;
END
如上,存储过程中开启事务,先查询debit_balance,查询结果插入testvalue数据表,然后更新debit_balance(加1)
100个并发操作
客户端,同时开启一百个线程,每个线程都调用存储过程Test。
假设数据表c_account_customer中的字段debit_balance初始值为10000.
那么客户端程序执行完成后,理想情况下debit_balance=100、testvalue 数据表有100数据,val值为0-100。
看看结果:
如上,数据未达到预期的原因是在某一时刻,事务A读取debit_balance值时并未锁住数据,事务B(或许更多事务)此时也读到了相同的值,
那么这些事务总体只对debit_balance进行了加1操作。那么如何解决以上问题?即当一个事务读取数据时,锁住数据行,在提交之前,其他事务不能执行。
mysql :select ... for update
修改sql脚本:
CREATE DEFINER=`root`@`localhost` PROCEDURE `Test`(out debitb decimal(14,2))
BEGIN
START TRANSACTION ;
select @db:=debit_balance from c_account_customer where id=1 for update;
set debitb=@db;
insert into abacus.testvalue (val) values (@db);
update abacus.c_account_customer set debit_balance=@db+1 where id=1;
commit;
END
如上,在查询语句后面加上 for update
首先我们来看看并发操作后的结果:
通过图例,我们发现在查询语句中加入for update 解决了上面存在的问题。即我们在查询出debit_balance后就把当前的数据锁定,直到我们修改完毕后再解锁.
现在我们来看看 for update:
在事务中,SELECT ... FOR UPDATE 同一笔数据时会等待其它事务结束后才执行,一般SELECT ... 则不受此影响拿上面的实例来说,当我执行select debit_balance from c_account_customer where id=1 for update;后。我在另外的事务中如果再次执行select debit_balance from c_account_customer where id=1 for update;则第二个事务会一直等待第一个事务的提交,此时第二个查询处于阻塞的状态,但是如果我是在第二个事务中执行select debit_balance from c_account_customer where id=1;则能正常查询出数据,不会受第一个事务的影响 (经过测试)。
补充:MySQL select…for update的Row Lock与Table Lock
上面我们提到,使用select…for update会把数据给锁住,不过我们需要注意一些锁的级别,MySQL InnoDB默认Row-Level Lock,所以只有「明确」地指定主键,MySQL 才会执行Row lock (只锁住被选取的数据) ,否则MySQL 将会执行Table Lock (将整个数据表单给锁住)。