编辑
术式之后皆为逻辑，一切皆为需求和实现。希望此文能从需求、现状和解决方式的角度帮大家理解隔离级别。
隔离级别的产生
在串型执行的条件下，数据修改的顺序是固定的、可预期的结果，但是并发执行的情况下，数据的修改是不可预期的，也不固定，为了实现数据修改在并发执行的情况下得到一个固定、可预期的结果，由此产生了隔离级别。
所以隔离级别的作用是用来平衡数据库并发访问与数据一致性的方法。
事务的4种隔离级别
READUNCOMMITTED未提交读，可以读取未提交的数据。READCOMMITTED已提交读，对于锁定读(selectwithforupdate或者forshare)、update和delete语句，InnoDB仅锁定索引记录，而不锁定它们之间的间隙，因此允许在锁定的记录旁边自由插入新记录。Gaplocking仅用于外键约束检查和重复键检查。REPEATABLEREAD可重复读，事务中的一致性读取读取的是事务第一次读取所建立的快照。SERIALIZABLE序列化
在了解了4种隔离级别的需求后，在采用锁控制隔离级别的基础上，我们需要了解加锁的对象(数据本身间隙)，以及了解整个数据范围的全集组成。
数据范围全集组成
SQL语句根据条件判断不需要扫描的数据范围（不加锁）；
SQL语句根据条件扫描到的可能需要加锁的数据范围；
以单个数据范围为例，数据范围全集包含：（数据范围不一定是连续的值，也可能是间隔的值组成）
1.数据已经填充了整个数据范围：（被完全填充的数据范围，不存在数据间隙）
整形，对值具有唯一约束条件的数据范围1～5，已有数据1、2、3、4、5，此时数据范围已被完全填充；
整形，对值具有唯一约束条件的数据范围1和5，已有数据1、5，此时数据范围已被完全填充；
2.数据填充了部分数据范围：（未被完全填充的数据范围，是存在数据间隙）
整形的数据范围1～5，已有数据1、2、3、4、5，但是因为没有唯一约束，所以数据范围可以继续被1～5的数据重复填充；
整形，具有唯一约束条件的数据范围1～5，已有数据2，5，此时数据范围未被完全填充，还可以填充1、3、4；
3.数据范围内没有任何数据（存在间隙）
如下：
整形的数据范围1～5，数据范围内当前没有任何数据。
在了解了数据全集的组成后，我们再来看看事务并发时，会带来的问题。
无控制的并发所带来的问题
并发事务如果不加以控制的话会带来一些问题，主要包括以下几种情况。
1.范围内已有数据更改导致的：
更新丢失：当多个事务选择了同一行，然后基于最初选定的值更新该行时，由于每个事物不知道其他事务的存在，最后的更新就会覆盖其他事务所做的更新；
脏读：一个事务正在对一条记录做修改，这个事务完成并提交前，这条记录就处于不一致状态。这时，另外一个事务也来读取同一条记录，如果不加控制，第二个事务读取了这些“脏”数据，并据此做了进一步的处理，就会产生提交的数据依赖关系。这种现象就叫“脏读”。
2.范围内数据量发生了变化导致：
不可重复读：一个事务在读取某些数据后的某个时间，再次读取以前读过的数据，却发现其读出的数据已经发生了改变，或者某些记录已经被删除了。这种现象就叫“不可重复读”。
幻读：一个事务按相同的查询条件重新读取以前检索过的数据，却发现其他事务插入了满足其查询条件的新数据，这种现象称为“幻读”。可以简单的认为满足条件的数据量变化了。
因为无控制的并发会带来一系列的问题，这些问题会导致无法满足我们所需要的结果。因此我们需要控制并发，以实现我们所期望的结果(隔离级别)。
MySQL隔离级别的实现
InnoDB通过加锁的策略来支持这些隔离级别。
行锁包含：
RecordLocks索引记录锁，索引记录锁始终锁定索引记录，即使表中未定义索引，这种情况下，InnoDB创建一个隐藏的聚簇索引，并使用该索引进行记录锁定。
GapLocks间隙锁是索引记录之间的间隙上的锁，或者对第一条记录之前或者最后一条记录之后的锁。间隙锁是性能和并发之间权衡的一部分。对于无间隙的数据范围不需要间隙锁，因为没有间隙。
Next-KeyLocks索引记录上的记录锁和索引记录之前的gaplock的组合。假设索引包含10、11、13和20。可能的next-keylocks包括以下间隔，其中圆括号表示不包含间隔端点，方括号表示包含端点：
(负无穷大,10](10,11](11,13](13,20](20,正无穷大)对于最后一个间隔，next-key将会锁定索引中最大值的上方，
上确界伪记录的值高于索引中任何实际值。
上确界不是一个真正的索引记录，因此，实际上，这个next-key只锁定最大索引值之后的间隙。
基于此，当获取的数据范围中，数据已填充了所有的数据范围，那么此时是不存在间隙的，也就不需要gaplock。
对于数据范围内存在间隙的，需要根据隔离级别确认是否对间隙加锁。
默认的REPEATABLEREAD隔离级别，为了保证可重复读，除了对数据本身加锁以外，还需要对数据间隙加锁。
READCOMMITTED已提交读，不匹配行的记录锁在MySQL评估了where条件后释放。
对于update语句，InnoDB执行semi-consistent读取，这样它会将最新提交的版本返回到MySQL，
以便MySQL可以确定该行是否与update的where条件相匹配。
现在我们来验证以下MySQL对于隔离级别的实现是否符合预期。
场景演示
下面整理几种场景，确定其所加锁：
数据准备：
CREATETABLE`t`(`a`int(11)NOTNULL,`b`int(11)DEFAULTNULL,`c`int(11)DEFAULTNULL,`d`int(11)DEFAULTNULL,`e`int(11)DEFAULTNULL,PRIMARYKEY(`a`),UNIQUEKEY`c`(`c`,`d`,`e`),KEY`b`(`b`));insertintotvalues(1,2,1,2,3),(2,2,1,2,4),(3,3,1,2,5),(4,4,2,3,4),(5,5,3,3,5),(6,7,4,5,5),(7,10,5,6,7),(8,13,5,3,1),(9,20,6,9,10),(10,23,7,7,7);
说明：
sessionASQL1SQL2....sessionBSQLNSQLN+1...上面的语句都是按照时间顺序排序。
所有的测试数据都是基于数据准备好的原始数据，每次测试完成，请自我修复现场。
场景一
rr模式+唯一索引筛选：
数据：
数据范围已被数据完全填充
（1）已有数据的更改sessionAstarttransaction;updatetseta=11wherea=3;#持有RecordLocks（a=3）sessionBupdatetseta=12wherea=3;#等待a=3的RecordLocks，直到sessionA将其释放/等锁超时数据范围有数据，但未被完全填充
（2）已有数据的更改sessionAstarttransaction;updatetsetb=11wherea=10;#持有RecordLocks（a=10），有Next-KeyLocks(a10)sessionBupdatetsetb=12wherea=10;#等待a=10的RecordLocks，直到sessionA将其释放/等锁超时间隙的填充sessionAstarttransaction;updatetsetb=11wherea=10;
#持有RecordLocks（a=10），有Next-KeyLocks(a10)sessionBinsertintotvalues(11,1,21,1,1);#插入等待，因为存在a10的Next-KeyLocks数据范围内没有数据
（3）间隙的填充sessionAstarttransaction;updatetsetb=11wherea=anda=;#存在GapLockssessionBinsertintotvalues(,1,21,1,1);#插入等待，因为存在(10,无穷大)的GapLocks，a最大的一个值是10insertintotvalues(11,1,1,2,2);#插入等待，因为存在(10,无穷大)的Gap.Locks，a最大的一个值是10updatetsetb=8wherea=10;#更改成功，因为sessionA并未持有RecordLocksupdatetsetb=23wherea=10;#恢复现场
场景二
rc模式+唯一索引筛选：
（4）已有数据的更改sessionAstarttransaction;updatetseta=11wherea=3;#持有RecordLocks（a=3）sessionBupdatetseta=12wherea=3;#等待a=3的RecordLocks，直到sessionA将其释放/等锁超时数据范围有数据，但未被完全填充
（5）已有数据的更改sessionAstarttransaction;updatetsetb=11wherea=10;#持有RecordLocks（a=10），无Next-KeyLocks(a10)sessionBupdatetsetb=12wherea=10;#等待a=10的RecordLocks，直到sessionA将其释放/等锁超时间隙的填充sessionAstarttransaction;updatetsetb=11wherea=10;
#持有RecordLocks（a=10），无Next-KeyLocks(a10)sessionBinsertintotvalues(11,1,21,1,1);#插入成功deletefromtwherea=11;#恢复现场数据范围内没有数据
（6）间隙的填充sessionAstarttransaction;updatetsetb=11wherea=anda=;#无对应的索引，所以无RecordLocks，无Next-KeyLockssessionBinsertintotvalues(,1,21,1,1);#插入成功deletefromtwherea=;#恢复现场
场景三
rr模式+非唯一索引筛选：（非唯一索引筛选的情况下，不存在数据完全填充的场景）
数据范围有数据，但未被完全填充
（7）**已有数据的更改**sessionAstarttransaction;updatetsete=7whereb=2ande=4;#获取非唯一索引，命中b=2的索引值，b=2的索引值对应多条记录。此时有RecordLocks，加在非唯一索引上sessionBupdatetsete=7whereb=2ande=10;#sessionA已获取了b=2的RecordLocks，sessionB等待sessionA将其释放/等锁超时即使该条件命中的是空记录间隙的填充sessionAstarttransaction;
updatetsetd=6whereb=5andb=7;#获取了b=5和b=7的RecordLocks，和(5,7)的GapLockssessionBinsertintotvalues(11,6,11,12,13);#插入b=6的记录，插入等待，存在b的数据范围(5,7)的GapLocks。数据范围内没有数据
（8）间隙的填充sessionAstarttransaction;updatetsetb=whereb=;#b=命中了空的数据范围，所以无RecordLocks，但存在(23,正无穷)的GapLockssessionBinsertintotvalues(,,,,);#插入等待，等待(23,正无穷)的GapLocks的释放insertintotvalues(,24,3,4,60);
#插入等待，等待(23,正无穷)的Gaplocks的释放updatetsetb=12whereb=23;#更新成功，因为sessionA并未获取RecordLocks，
所以不会阻止已有行的更新updatetsetb=23whereb=12;#恢复现场
场景四
rc模式+非唯一索引筛选：（非唯一索引筛选的情况下，不存在数据完全填充的场景）
（9）已有数据的更改sessionAstarttransaction;updatetsete=7whereb=2ande=4;#获取非唯一索引，命中b=2的索引值，b=2的索引值对应多条记录。此时有RecordLocks，加在非唯一索引上sessionBupdatetsete=7whereb=2ande=10;
#sessionA已获取了b=2的RecordLocks，sessionB等待sessionA将其释放/等锁超时，即使该条件命中的是空记录间隙的填充sessionAstarttransaction;updatetsetd=6whereb=5andb=7;#获取了b=5和b=7的RecordLocks，无Next-KeyLockssessionBinsertintotvalues(11,6,11,12,13);#插入成功，因为无Next-KeyLocks数据范围内没有数据
（10）间隙的填充sessionAstarttransaction;updatetsetb=whereb=;#b=命中了空的数据范围，所以无RecordLocks，无Next-KeyLockssessionBinsertintotvalues(,,,,);#插入成功，因为无Next-KeyLocks
场景五
rr模式+无索引筛选：（无索引筛选的情况下，不存在数据完全填充的场景）
（11）已有数据的更改sessionAstarttransaction;updatetsetc=whered=2;#d=2对应a=1、a=2、a=3的记录，因为where条件未使用索引，故只能全表扫描，并对所有行加RecordLocks，并且在间隙中加上GapLockssessionBupdatetsetb=wherea=1;
#等待sessionA获取的a=1的X锁间隙的填充因为where条件并未使用索引，所以最终加锁都回归到了对基表的聚簇索引加锁，但是where条件未使用索引，自然更无唯一约束，所以逻辑上可以认为除where命中的行以外的其他范围都是间隙。而实际上因为通过聚簇索引加锁，所以在每两个聚簇索引之间才会加上GapLocks。
sessionAstarttransaction;updatetsetc=whered=2;#d=2对应a=1、a=2、a=3的记录，因为where条件未使用索引，故只能全表扫描，并对所有聚簇索引加RecordLocks，并且加上Next-KeyLockssessionBupdatetsetb=50wherea=8;#等待sessionA获取的a=8的X锁insertintotvalues(,30,30,40,);#等待Next-KeyLocks数据范围内没有数据
（12）间隙的填充因为where条件并未使用索引，所以最终加锁都回归到了对基表的聚簇索引加锁，但是where条件未使用索引，自然更无唯一约束，所以逻辑上可以认为除where命中的行以外的其他范围都是间隙。而实际上因为通过聚簇索引加锁，所以在每两个聚簇索引之间才会加上GapLocks。
sessionAstarttransaction;updatetsetc=whered=20;#因为where条件未使用索引，故只能全表扫描，并对所有聚簇索引加RecordLocks，并且加上Next-KeyLockssessionBupdatetsetb=50wherea=8;#等待sessionA获取的a=8的X锁insertintotvalues(,3,,20,4);#等待Next-KeyLocks
场景六
rc模式+无索引筛选：（无索引筛选的情况下，不存在数据完全填充的场景）
数据范围有数据，但未被完全填充（
13）已有数据的更改sessionAstarttransaction;updatetsetc=whered=2;#对应a=1、a=2、a=3的记录,因为where条件未使用索引，故只能全表扫描，并对a=1、a=2、a=3聚簇索引加RecordLocks，但是无Next-KeyLockssessionBupdatetsetb=wherea=1;#等待sessionA获取的a=1的RecordLocks间隙的填充因为where条件并未使用索引，所以最终加锁都回归到了对基表的聚簇索引加锁，但是where条件未使用索引，自然更无唯一约束，所以逻辑上可以认为除where命中的行以外的其他范围都是间隙。
而实际上因为通过聚簇索引加锁，所以在每两个聚簇索引之间才会加上GapLocks。sessionAstarttransaction;updatetsetc=whered=2;#对应a=1、a=2、a=3的记录，因为where条件未使用索引，故只能全表扫描，并对a=1、a=2、a=3聚簇索引加RecordLocks，但是无Next-KeyLockssessionBupdatetsetb=50wherea=8;#成功，因为a=8并未被sessionA加锁insertintotvalues(,30,30,2,);#成功，因为不存在GapLocksnext-KeyLocks数据范围内没有数据
（14）间隙的填充*sessionAstarttransaction;updatetsetc=whered=20;#无RecordLocks，也无Next-KeyLockssessionBinsertintotvalues(,3,,20,4);#成功deletefromtwherea=;#恢复现场
总结延展：
唯一索引存在唯一约束，所以变更后的数据若违反了唯一约束的原则，则会失败。
当where条件使用二级索引筛选数据时，会对二级索引命中的条目和对应的聚簇索引都加锁；所以其他事务变更命中加锁的聚簇索引时，都会等待锁。
行锁的增加是一行一行增加的，所以可能导致并发情况下死锁的发生。
例如，
在sessionA对符合条件的某聚簇索引加锁时，可能sessionB已持有该聚簇索引的RecordLocks，而sessionB正在等待sessionA已持有的某聚簇索引的RecordLocks。
sessionA和sessionB是通过两个不相干的二级索引定位到的聚簇索引。
sessionA通过索引idA，sessionB通过索引idB。
当where条件获取的数据无间隙时，无论隔离级别为rc或rr，都不会存在间隙锁。
比如通过唯一索引获取到了已完全填充的数据范围，此时不需要间隙锁。
间隙锁的目的在于阻止数据插入间隙，所以无论是通过insert或update变更导致的间隙内数据的存在，都会被阻止。
rc隔离级别模式下，查询和索引扫描将禁用gaplocking，此时gaplocking仅用于外键约束检查和重复键检查（主要是唯一性检查）。
rr模式下，为了防止幻读，会加上GapLocks。
事务中，SQL开始则加锁，事务结束才释放锁。
就锁类型而言，应该有优化锁，锁升级等，例如rr模式未使用索引查询的情况下，是否可以直接升级为表锁。
就锁的应用场景而言，在回放场景中，如果确定事务可并发，则可以考虑不加锁，加快回放速度。
锁只是并发控制的一种粒度，只是一个很小的部分：
从不同场景下是否需要控制并发，(已知无交集且有序的数据的变更，MySQL的MTS相同前置事务的多事务并发回放)
并发控制的粒度，(锁是一种逻辑粒度，可能还存在物理层和其他逻辑粒度或方式)
相同粒度下的优化，(锁本身存在优化，如IX、IS类型的优化锁)
粒度加载的安全性能(如获取行锁前，先获取页锁，页锁在执行获取行锁操作后即释放，无论是否获取成功)等多个层次去思考并发这玩意。
关键字：爱可生、MySQL数据库、数据库运维管理、开源数据库解决方案