行锁与隔离级别案例分析

更多内容，可前往深入理解MySQL锁与事务隔离级别查看
现有如下表：

CREATE TABLE `account` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT NULL,
  `balance` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8;

一个session开启事务更新不提交，另一个session更新同一条记录会阻塞，更 新不同记录时不会阻塞。

1 读未提交

（1）打开一个客户端A，设置当前事务模式为read uncommitted（读未提交）并开启事务,查询初始化数据

①设置隔离级别并开启事务

set tx_isolation='read-uncommitted';

②查询表的初始数据

select * from account;

（2）在客户端A的事务提交之前，打开另一个客户端B，设置当前事务模式为read uncommitted（未提交读）并开始事务，更新表account：
①更新隔离级别为读未提交

set tx_isolation='read-uncommitted';

②查询初始化数据

③、更新数据

（3）这时，虽然客户端B的事务还没提交，但是客户端A就可以查询到B已经更新的数据：

（4）一旦客户端B的事务因为某种原因回滚，所有的操作都将会被撤销，那 客户端A查询到的数据其实就是脏数据：

（5）在客户端A执行更新语句update account set balance = balance - 50 where id =1，lilei的balance没有变成350，居然是400，是不是很奇怪，数据不 一致啊，如果你这么想就太天真 了，在应用程序中，我们会用400-50=350，并 不知道其他会话回滚了，要想解决这个问题可以采用读已提交的隔离级别

2 读已提交

（1）打开一个客户端A，设置当前事务模式为read committed（读已提交）并开启事务,查询初始化数据

①设置隔离级别并开启事务

set tx_isolation='read-committed';

②查询表的初始数据

select * from account;

（2）在客户端A的事务提交之前，打开另一个客户端B，设置当前事务模式为read committed（读已提交）并开始事务，更新表account：
①更新隔离级别为读已提交

set tx_isolation='read-committed';

②查询初始化数据

③、更新数据

（3）这时，客户端B的事务还没提交，客户端A不能查询到B已经更新的数 据，解决了脏读问题：

（4）客户端B的事务提交

（5）客户端A执行与上一步相同的查询，结果 与上一步不一致，即产生了不可重复读的问题（同一事务中执行同一SQL返回不同的结果）

3 可重复读

（1）打开一个客户端A，设置当前事务模式为repeatable read（可重复读）并开启事务,查询初始化数据

①设置隔离级别并开启事务

set tx_isolation='repeatable-read';

②查询表的初始数据

select * from account;

（2）在客户端A的事务提交之前，打开另一个客户端B，设置当前事务模式为repeatable read（可重复读）并开始事务，更新表account：
①更新隔离级别为可重复读

set tx_isolation='repeatable-read';

②查询初始化数据

③、更新数据

（3）这时，提交客户端B的事务，查看客户端A的数据

（4）在客户端A，接着执行update account set balance = balance - 50 where id = 1，balance没有变成400-50=350。
lilei的balance值用的是sessionB中的350来算的，所以是300，数据的一致性倒是没有被破坏。可重复读的隔离级别下使用了MVCC(multi-version concurrency control)机（多版本并发控制机制）。
select操作不会更新版本号，是快照读（历史版本）；
insert、update和delete会更新版本号，是当前读（当前版本）。

（5）客户端A执行与上一步相同的查询，结果 与上一步不一致，即产生了不可重复读的问题（同一事务中执行同一SQL返回不同的结果）

关于MVCC机制，具体看前往MySQL的MVCC机制详解进行查看

4 幻读

（1）打开一个客户端A，开启事务，查询初始化数据

（2）手动在数据库中插入一条记录，然后再去客户端A查询数据


发现查询出的数据还是第一次查询的三条数据。

（3）更新上一步手动插入的数据

发现更新成功了。

（4）再次查询数据

发现数据确实已被更新，且也可以查询出来了。

这种情况就是幻读，很魔幻的感觉，更新了，就多了一条数据了。
幻读的情况，可设置事务隔离级别为串行化可解决（但是效率低下，几乎不会使用，这里不进行介绍）。

问：Mysql默认级别是repeatable-read，有办法解决幻读问题吗？
答：间隙锁在某些情况下可以解决幻读问题
比如：现在有如下数据

可以看到，id中4和10之间有个间隙、10和20之间是有间隙的（之间还可以插入一些11、12…等数据，还有一些空白的id没有被使用到）

开启事务

查询数据

更新数据

只要事务不提交，那么id 4~10、10 ~ 20之间的间隙就会被加锁。
我们可以手动在数据库里插入数据来验证

直到我们回滚或者提交事务会后，上述阻塞的地方就会正常

以此看来，间隙锁是可以帮助我们处理幻读的问题。
一旦开启间隙锁，则加锁的部分不再允许插入（未加锁的部分依然可以正常插入），那么session中查询的数据永远都是之前的记录

无索引行锁会升级为表锁：锁主要是加在索引上，如果对非索引字 段更新, 行锁可能会变表锁
InnoDB的行锁是针对索引加的锁，不是针对记录加的锁。并且该索引不能失效，否则都会从行锁升级为表锁。


锁定某一行还可以用lock in share mode(共享锁) 和for update(排它锁)，
例如：select * from test_innodb_lock where a = 2 for update;
这样其他session只能读这行数据，修改则会被阻塞，直到锁定行的session 提交

5 结论

      Innodb存储引擎由于实现了行级锁定，虽然在锁定机制的实现方面所带来的 性能损耗可能比表级锁定会要更高一下，但是在整体并发处理能力方面要远远优 于MYISAM的表级锁定的。当系统并发量高的时候，Innodb的整体性能和 MYISAM相比就会有比较明显的优势了。
      Innodb但是，Innodb的行级锁定同样也有其脆弱的一面，当我们使用不当的时候， 可能会让Innodb的整体性能表现不仅不能比MYISAM高，甚至可能会更差。

6 优化建议

（1）尽可能让所有数据检索都通过索引来完成，避免无索引行锁升级为表锁
（2）合理设计索引，尽量缩小锁的范围 尽可能减少检索条件范围，避免间隙锁
（3） 尽量控制事务大小，减少锁定资源量和时间长度，涉及事务加锁的sql 尽量放在事务最后执行
（4）尽可能低级别事务隔离