| 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 (将整个数据表单给锁住)。
   |