本文是对数据库锁机制的总结。对于数据库锁的了解，是区分一个程序员，尤其是Java程序员中高级的重要标志。在日常开发中，数据库锁也是我们容易踩坑的地方。如果你的系统没有被高并发大访问量流量洗礼，可能你压根没有遇到过锁问题。可一旦有朝一日你有幸遇到了大流量，恰你不幸没经受住这波幸福的考验，那损失不是一般的小，说不定领导会找你喝茶。好了，说了这些，为了让你明白锁机制的重要性，接下来我们一步步体验MySQL的锁机制之旅。
一、什么是锁
二、锁的分类
三、事务隔离级别
四、MVCC
五、一致性非锁定读与一致性锁定读
六、 InnoDB锁的类型
七、 InnoDB行锁几种算法
八、测试case
九、 特殊case
十、锁的兼容性
十一、死锁
1、什么是死锁
2、不同行互相操作一个例子
3、锁兼容性的一个死锁例子
鉴于篇幅，本文仅涉及提纲一至五部分，其余留给后续系列文章介绍。
一、什么是锁
锁机制是用于管理对共享资源的并发访问。
在数据库中，lock与latch都可以被称为锁。latch 一般称为闩锁(轻量级的锁) 因为其要求锁定的时间非常短, lock的对象是事务，用来锁定的是数据库中的对象，如表、页、行。
两种锁的区别
latch一般用于锁住事务号，内存等一些资源。而lock一般用于锁住记录，latch基本用户感知不到，lock可能是我们需要经常感知到的，下面介绍的锁为lock锁。
二、 锁的分类
MySQL存在多种不同的引擎，各种不同引擎类型面对的使用场景不一样，不同引擎之间的锁粒度可能有差别。例如InnoDB能支持行级锁，MyISAM支持表级锁，BDB支持页级锁，他们的特定如下：
1: 行级锁具有较高的并发性，比较适合并发度较高的场景，同时也更耗费资源。 但是如果锁住大量的记录，会比页级锁或者表级锁更慢，需要获取大量锁资源。
2:表级锁消耗资源更少，但是并发读较低。比较适合需要经常锁住大量数据的场景。
3:页级锁界于行锁以及表级锁之间，但是在无法解决热点数据的并发问题。
接下来分别创建两张不同引擎的表，分别演示分别在myisam以及InnoDB大量数据插入的情况下，另一个会话更新一条数据的block状态。以及锁类型，模拟过程为:
(1):创建一张myisam(myisam_lock_test)或者是InnoDB引擎的表(innodb_lock_test)。
(2):开启一个会话sessionA，插入一条数据。
(3):使用load指令进行大量数据插入。
(4):开启另一个会话更新步骤二刚插入的数据。
表结构均为:
测试表结构
myisam测试
sessionA:
load data infile '/Users/it2eye/mysql_lock/create/data.txt' into table myisam_lock_test(name); sessionB:
update myisam_lock_test set name='123' where id=1;
分别执行上述两条语句后，update一直阻塞住，并且等待表锁
InnoDB测试
sessionA:
load data infile '/Users/it2eye/mysql_lock/create/data.txt' into table innodb_lock_test(name); sessionB:
update innodb_lock_test set name='123' where id=1;
执行语句后，update并不会阻塞并且很快执行完毕
三、事务隔离级别
数据库事务的隔离级别有4种，由低到高分别为：
1、Read uncommitted (读未提交)
读未提交，顾名思义，就是一个事务可以读取另一个未提交事务的数据。事务中的修改，即使没有提交，对其它事务也是可见的。这种现象也被称为脏读。
事例：老板要给程序员发工资，程序员的工资是3.6万/月。但是发工资时老板不小心按错了数字，按成3.9万/月，该钱已经打到程序员的户口，但是事务还没有提交，就在这时，程序员去查看自己这个月的工资，发现比往常多了3千元，以为涨工资了非常高兴。但是老板及时发现了不对，马上回滚差点就提交了的事务，将数字改成3.6万再提交。
分析：实际程序员这个月的工资还是3.6万，但是程序员看到的是3.9万。他看到的是老板还没提交事务时的数据。这就是脏读。
那怎么解决脏读呢？Read committed！读提交，能解决脏读问题。
2、Read committed(读已提交)
读提交，顾名思义，就是一个事务要等另一个事务提交后才能读取数据。一个事务只能看到已提交的事务修改，换句话说，一个事务从开始到提交之前，所做的任何修改对其它事务都是可见的。
事例：程序员拿着信用卡去享受生活(卡里当然是只有3.6万)，当他埋单时(程序员事务开启)，收费系统事先检测到他的卡里有3.6万，就在这个时候！！程序员的妻子要把钱全部转出充当家用，并提交。当收费系统准备扣款时，再检测卡里的金额，发现已经没钱了(第二次检测金额当然要等待妻子转出金额事务提交完)。程序员就会很郁闷，明明卡里是有钱的…
分析：这就是读提交，若有事务对数据进行更新(UPDATE)操作时，读操作事务要等待这个更新操作事务提交后才能读取数据，可以解决脏读问题。但在这个事例中，出现了一个事务范围内执行两次同样的查询却返回了不同结果，这个级别也叫不可重复读。
那怎么解决可能的不可重复读问题？下面第3种Repeatable read ！
3、Repeatable read(可重复读)
重复读，就是在开始读取数据(事务开启)时，不再允许修改操作。该级别保证了在一个事务中多次读取同样的记录的结果是一致的。但还是没解决幻读(Phantom Read)的问题(下面有举例介绍)。该级别是MySQL的默认事务隔离级别。
事例：程序员拿着信用卡去享受生活(卡里当然是只有3.6万)，当他埋单时(事务开启，不允许其他事务的UPDATE修改操作)，收费系统事先检测到他的卡里有3.6万。这个时候他的妻子不能转出金额了。接下来收费系统就可以扣款了。说明可重复读可以解决不可重复读问题。
什么时候会出现幻读？
事例：程序员某一天去消费，花了2千元，然后他的妻子去查看他今天的消费记录(全表扫描FTS，妻子事务开启)，看到确实是花了2千元，就在这个时候，程序员花了1万买了一部电脑，即新增INSERT了一条消费记录，并提交。当妻子打印程序员的消费记录清单时(妻子事务提交)，发现花了1.2万元，似乎出现了幻觉，这就是幻读。
现在你明白了，所谓幻读：指的是当某个事务在读取某个范围的记录时，另一个事务又在该范围内插入了新的记录，当之前事务再次读取该范围的记录时，会产生幻行(Phantom Row)。不过MySQL的InnoDB存储引擎可以通过gap锁解决幻读的问题。
分析：可重复读可以解决不可重复读问题。到这里，你应该豁然开朗了，不可重复读对应的是修改，即UPDATE操作。但是可能还会有幻读问题。因为幻读问题对应的是插入INSERT操作，而不是UPDATE操作。
那怎么解决幻读问题？Serializable！
4、Serializable (可串行化)
这是最高的隔离级别。在该级别下，强制事务串行化顺序执行，可以避免脏读、不可重复读与幻读。但是这种事务隔离级别效率低下，比较耗数据库性能，一般不使用。Serializable 会在读取的每一行数据上都加锁，可能导致大量的超时和锁争用的问题。
不同事务隔离级别可能产生问题
值得一提的是：大多数数据库默认的事务隔离级别是Read committed，比如Sql Server , Oracle。Mysql的默认隔离级别是Repeatable read。
提交读的幻读问题
会话A
会话B插入数据
会话A出现幻读问题(将满足index_key为1的记录的no_index_key更新为2，但是执行查询发现仍然有一条数据未进行修改,就像发生幻觉一样)
可重复读gap锁解决幻读问题
会话A
会话b执行插入操作被block住后重启事务
执行select * from information_schema.innodb_locks;
可以看到锁类型为x锁，以及gap锁，后面系列文章将详细介绍下InnoDB行锁算法。
四、 MVCC
大部分的MySQL的存储 引擎，比如InnoDB并不是简简单单的使用行锁机制。它们都使用了行锁结合一种提高并发的技术，被称为MVCC(多版本并发控制)。MVCC并不单单应用在MySQL中，其他的数据库如Oracle,PostgreSQL也使用这个技术。
MVCC避免了许多需要加锁的情形以及降低消耗。这取决于它实现的方式，它允许非阻塞读取，在写的操作的时候阻塞必要的记录。
MVCC保存了某一时刻数据的一个快照。意思就是无论事物运行了多久，它们都能看到一致的数据。也就是说在相同的时间下，不同的事物看相同表的数据是不同的。
每个存储引擎实现MVCC的方式不同。有许多种包含了乐观(optimistic)和悲观(pessimistic)的并发控制。下面用InnoDB的行为来举例说明MVCC工作方式。
InnoDB实现MVCC的方法是，它存储了每一行的两个(1)额外的隐藏字段，这两个隐藏字段分别记录了行的创建的时间和删除的时间。在每个事件发生的时候，每行存储版本号，而不是存储事件实际发生的时间。每次事物的开始这个版本号都会增加。自记录时间开始，每个事物都会保存记录的系统版本号。依照事物的 版本来检查每行的版本号。
SELECT
InnoDB检查每行数据，确保他们符合两个标准：
1、InnoDB只查找版本早于当前事务版本的数据行(也就是数据行的版本必须小于等于事务的版本)，这确保当前事务读取的行都是事务之前已经存在的，或者是由当前事务创建或修改的行。
2、行的删除操作的版本一定是未定义的或者大于当前事务的版本号。确定了当前事务开始之前，行没有被删除。
符合了以上两点则返回查询结果。
INSERT
InnoDB为每个新增行记录当前系统版本号作为创建ID。
DELETE
InnoDB为每个删除行的记录当前系统版本号作为行的删除ID。
UPDATE
InnoDB复制了一行。这个新行的版本号使用了系统版本号。它也把系统版本号作为了删除行的版本。
对于InnoDB可重复读来说
开启一个事务后，第一次进行查询操作。会创建一个当前快照读的一个数据结构，readView，主要包含三方面的内容，当前活动事务的最小事务号up_limit_id，当前活动事务的最大事务号low_limit_id，以及非自身的其它活动事务id组成的数组，trx_ids[],
注意的是,上述的当前事务版本号是当前活动事务号的版本。
五、 一致性非锁定读与一致性锁定读
一致性非锁定读
指InnoDB存储引擎通过行多版本控制(multi versioning)的方式来读取当前执行时间数据库中行的数据，快照读，读一般不加行级lock锁。
一致性锁定读
需要加锁显式的保证数据的一致性。读需要加lock锁
select **** for update
select **** lock in share mode
insert….where
update *** where…..
我是一名简单可靠、纯洁可爱的分享者，若您喜欢我的文章，欢迎转发，也欢迎关注我。
我会经常分享让你喜欢的互联网技术知识。
292
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
