在探讨锁以前，要从事务管理的隔离级别先谈起
Mysql事务管理的四个隔离级别，等级从低到高为
读未提交【read uncommitted】（会出現脏读、不能反复读和幻读的难题）
读已提交【read committed】（会出現不能反复读和幻读）
可反复读【repeatable read】（会出現幻读）
串行化【serializable】
隔离级别越高，安全系数越高，可是特性越低。Mysql事务管理的默认设置等级是可反复读，而oracle的事务管理是读已提交的等级。因为读未提交的网络信息安全无法得到确保，而串行化这一等级下高并发度低，因此 大部分数据库查询的隔离级别全是选的读已提交和可反复读这二种。
下边再介绍一下什么叫脏读、不能反复读和幻读
A和B2个手机客户端另外打开事务管理并在事务管理中实行一些实际操作
脏读场景：（隔离级别设成读未提交）
B先改动一条数据信息X，实行了update把x从x=10改成x=20，但是都还没实行commit；这时A在事务管理中读取数据X, 实行select，这时A查到20。
不能反复读场景：（隔离级别设成读已提交，这时脏读不容易出現，可是不能反复读的难题却出現了）
- B先改动一条数据信息X，实行了update把x从x=10改成x=20，但是都还没实行commit；这时A在事务管理中读取数据X, 实行了select，这时A查到10（非常好，这才应该是一切正常的）。
- 然后，B实行了commit，这时A再实行 select x，获得20，可是A都还没commit，换句话说A在同一个事务管理中对数据信息x实行了2次select，2次select的結果竟然不一样，A竟然在自身的事务管理里边读到别的手机客户端事务管理改动递交后的数据信息值（那样就表明数据信息不安全了）。
幻读场景：（隔离级别设为可反复读，这时脏读和不能反复读不容易出現，可是幻读的难题却出現了）
什么叫幻读，你能了解为一个事务管理2次“当今读”获得的数据不一样。
A和B另外开启事务管理 begin;这时表t中仅有一条数据信息 (id=1, name=”zbp1”)
A先搜索：
Select * from t where id=2;
A沒有commit
发觉沒有id为2的数据信息，因此A要想插进一条id为2的数据信息。
可是这时 B比A先插入了一条数据信息
Insert into t values (null, “zbp2”);
随后B commit了。
随后A实行
Insert into t values (null, “zbp2”);
出错说：id为2的纪录早已存有了。
实行 select * from t;
发觉還是仅有 (id=1, name=”zbp1”)
我想问一下，幻读实际就是指上边的那一条句子，或是产生在哪句sql中。这个问题就可以看得出是不是真实了解幻读。
回答是，幻读产生在了A实行insert不成功这条sql。
A在insert新数据的情况下，会看一下当今最新数据中是不是有id为2的数据信息（是一个当今读），可是发觉有id为2的数据信息了，因此 就插进失败了。换句话说A在insert的情况下发生了幻读，幻读在这个事例中主要表现为事务管理A第一次select的情况下是沒有查出有id为2的数据信息，結果在insert中隐式查看是否有id为2的数据信息时却查到有。
该如何解决，能够应用临键锁，让A在一开始查看的情况下用 select * from t where id=2 for update 把(1, ∞)这一空隙给锁定。
空隙锁会在后面详细介绍行锁的情况下再详说。
在详细介绍幻读的情况下，很有可能大伙儿不理解什么叫做当今读。下面就详细介绍MVCC的有关定义，了解MVCC是以后了解锁体制的一个重要前提条件。
MVCC（多版本号高并发操纵）
是一种无需上锁就能让好几个事务管理高并发读写能力的体制。
下边大家看一下MVCC的最底层究竟发生什么事，它是怎样同过不上锁的方法保证高并发读写能力：
场景以下：
有一个innodb表t，t表格中仅有2个字段名（id和name）
|
Id |
Name |
Trx_id |
Roll_pointer |
|
1 |
Lilei |
100 |
诶，不是说表中仅有2个字段名吗？为何也有trx_id和roll_pointer呢？
实际上 trx_id 和 roll_pointer这两个字段名是innodb表的掩藏字段名。每一次事务管理都是会有一个事务管理id，当在一个事务管理中实行增改的实际操作的情况下，便会在实际操作相匹配的行中加上这一事务管理id到trx_id这一字段名中（select的情况下不容易）。
我们知道，在事务管理中的每一次实际操作的旧数据信息都是会被纪录到undo日志以便回退，undo日志一开始是载入缓冲区域，到commit的情况下才载入到硬盘。roll_pointer字段名纪录的是这一条行数据信息在undo日志中的详细地址，以便捷寻找旧数据信息的纪录开展回退。
返回主题，如今表格中仅有1条纪录，是由以前的一个事务管理id为100的事务管理建立的纪录。
现在有3个手机客户端A,B各自打开了事务管理。
1.A先实行update
Update t set name = ‘zbp’ where id = 1;
这时，最底层会对id为1的纪录转化成一个历史时间快照更新的纪录，放到undo日志中。随后再升级如今的id为1的数据信息的name字段名。以下：
当今数据信息变成
|
Id |
Name |
Trx_id |
Roll_pointer |
|
1 |
zbp |
101 |
X1 |
X1是历史记录在undo日志中的详细地址。
历史记录（放到undo日志中）
|
1 |
Lilei |
100 |
如今A都还没commit
2.B实行了
Select * from t where id=1;
这时载入到的name是lilei而不是zbp。由于事务管理B会载入历史记录而不容易去读A事务管理变更后的数据信息（也就是当今数据信息）。
请大伙儿留意一点：A实行了改动，会对数据信息上一个行级排他锁，并且都还没commit，因此 这一排它锁沒有释放出来。以后B开展查看同样的行竟然沒有被堵塞，表明了一点：B在select的情况下并沒有加一切锁，这就是MVCC的贡献，由于A是对当今数据信息开展锁上，而B是去读undo日志中的历史记录，因此 不用等候A释放出来锁。
为了更好地表述上边的状况，必须明确提出下边的定义：
快照更新读 和 当今读
MVCC高并发操纵中，读实际操作能够分为两大类：快照更新读 (snapshot read)与当今读 (current read)。
快照更新读，载入的是纪录的由此可见版本号 (有可能是历史版本)，无需上锁。
当今读，载入的是纪录的最新版，而且当今读回到的纪录，都是会再加上锁，确保别的事务管理不容易再高并发改动这条纪录。
快照更新读是哪些：一个一切正常的select…句子便是快照更新读。
当今读是什么：Insert句子、update句子、delete句子、表明上锁的select句子（select… LOCK IN SHARE MODE、select… FOR UPDATE）是当今读。为何insert、update、delete句子都归属于当今读（是的，改动以前会先隐式查看，这一查看时一个当今读）？当今读的SQL句子，InnoDB是逐一与MySQL Server层互动的。即先对一条符合条件的纪录上锁后，再回到给MySQL Server，当MySQL Server层做了DML实际操作后，再对下一条数据信息上锁并解决。
事务管理中同一数据信息的读–写和写–读实际操作能够高并发开展而不堵塞实际上便是依靠MVCC，它主要是根据在undo日志中纪录了数据信息的一个历史版本。当select 的情况下会产生一个快照更新读，因为快照更新读不用锁上，因此 在一个未提交的事务管理中，读–写和写–读都不容易产生堵塞。
假定沒有undo日志储存数据信息的历史版本得话，在读取数据的情况下就务必读当今数据信息，读当今数据信息就务必上一个读锁，这时读–写或是写–读便会产生一个堵塞。
再总结一下：当今读要锁上，快照更新都无需锁上。
