关于mysql:MySQL的锁到底有多少内容-再和腾讯大佬的技术面谈我还是小看锁了

对酒当歌，人生几何！朝朝暮暮，唯有己脱。

苦苦寻找找工作之间，殊不知今日之时乃我心之痛，难到是我不配领有工作嘛。自面试后他所谓的期待都过来一段时日，惋惜在下京东上的小金库都要见低啦。每每想到不禁心中一紧。正处尴尬之间，手机突然来了个短信预约后续面试。我即刻三下五除二拎包踢门而出。飞奔而去。

此刻面试门外首先映入眼帘的是一个红色似皮球的货色，似圆非圆。好奇冬瓜落地个别。上半段还有一段湿湿的局部，显得尤为入目。这是什么状况？

紧接着现身一名中年男子。他身着纯白色 T 桖衫的，一灰色宽松的休闲西裤，腰围至多得三十好几。外加一双夏日必备皮制凉鞋。只见，他正抬头看着手上的一张 A4 纸。透过一头彩色短发。满脸的赘肉横生。外加上那大腹便便快要把那 T 桖衫给撑爆的肚子。

看得我好生胆怯，不由得咽了咽口水，惟恐本人说错话。这宛如一颗肉粽呀。不退职场摸滚打拼 8、9 年，也不会有以后这现象。

什么是锁

面试官：: 你是来加入面试的吧？
吒吒辉： 不 不 不，我是来加入复试呢。

面试官：: 看到上次他人点评，MySQL 优化还阔以。那你先谈谈对锁的了解？

吒吒辉： 嘿嘿，还好！

锁 是计算机在进行 多 过程、线程 执行调度时强行限度资源拜访的同步机制，用于在 并发拜访 时保证数据的一致性、有效性；

锁是在执行多线程时，用于强行限度资源拜访的同步机制，即用在并发管制中保障对互斥的要求。

个别的锁是倡议锁（advisory lock），每个线程在拜访对应资源前都需获取锁的信息，再依据信息决定是否能够拜访。若拜访对应信息，锁的状态会扭转为锁定，因而其它线程此时不会来拜访该资源，当资源完结后，会复原锁的状态，容许其余线程的拜访。

有些零碎有强制锁（mandatory lock），若有未受权的线程想要拜访锁定的数据，在拜访时就会产生异样。

                          ---《维基百科》

锁的类型和利用原理

面试官：: 那个别数据库有哪些锁？个别怎么应用？

此刻，用我那目瞪口呆的眼神看向面试官，心田实属 难堪 + 胆怯 ，数据库不就是共享和互斥锁吗？
这样看来，是我太嫩。此处必有坑。殊不知此刻我心田已把你拿捏，定斩不饶。

吒吒辉： 数据库的锁依据不同划分形式有很多种说法，在业务拜访上有以下两种：

• 排他锁

在访问共享资源之前对其进行加锁，在拜访实现后进行解锁操作。加锁胜利后，任何其它线程申请来获取锁都会被阻塞，直到当火线自行开释锁。

线程 3 状态: 就绪、阻塞、执行

如解锁时，有一个以上的线程阻塞（资源已开释），那么所有尝试获取该锁的线程都被 CPU 认为 就绪状态，如果第一个就绪状态的线程又执行加锁操作，那么其余的线程又会进入就绪状态。在这种形式下，只能有一个线程拜访被互斥锁爱护的资源

故此，MySQL 的 SQL 语句加了互斥锁后，只有承受到申请并获取锁的线程才可能拜访和批改数据。因为互斥锁是针对线程访问控制而不是申请自身。

• 共享锁

被加锁资源是可被共享的，但仅限于读申请。它的写申请只能被获取到锁的申请独占。也就是加了共享锁的数据，只可能以后线程批改，其它线程只能读数据，并不能批改。

吒吒辉： 在 SQL 申请上可分为读、写锁。但实质还是对应对共享锁和排它锁。

面试官： 那 SQL 申请上不加锁怎么拜访？为啥说它们属于共享锁和排他锁? 这之间有何分割？

吒吒辉： 除加锁读外，还有一种不加锁读的状况。这种形式称为 快照读，读申请加锁称为共享读。

针对申请加共享、排它锁的起因在于，读申请天生是 幂等性 的，不管你读多少次数据不会发生变化，所以给读申请加上锁就应该为共享锁。不然怎么保障它的特点呢？
而写申请，自身就需对数据进行批改，所以就须要排它锁来保证数据批改的一致性。

吒吒辉： 如果依照锁的颗粒度划分看，就有 表锁和行锁

• 表锁：

是 MySQL 中最根本的锁策略，并且是开销最小的策略。并发解决较少。表锁由 MySQL 服务或存储引擎治理。少数状况由服务层治理，具体看 SQL 操作。

例如：服务器会为诸如 ALTER TABLE 之类的语句应用表锁
，而疏忽存储引擎的锁。

加锁机制:

它会锁定整张表。一个用户在对表进行写操作（插人、删除、更新等)前，须要先取得写锁，这会阻塞其余用户对该表的所有读写操作。只有没有写锁时，其余用户能力获取到读锁。

• 行锁:

锁定以后拜访行的数据，并发解决能力很强。但锁开销最大。具体视行数据多少决定。由 innoDB 存储引擎反对。

• 页级锁：

页级锁是 MySQL 中锁定粒度介于行级锁和表级锁两头的一种锁。表级锁速度快，但抵触多，行级抵触少，但速度慢。因而，采取了折衷的页级锁，一次锁定相邻的一组记录。由 BDB 存储引擎治理页级锁。

面试官： 为啥是表锁开销小，而不是行锁呢？毕竟表锁锁定是整张表

吒吒辉： 表锁锁定的是表没错，但它不是把表外面所有的数据行都上锁，相当于是封闭了表的入口，这样它只是须要判断每个申请是否能够获取到表的锁，没有就不锁定。
而行锁是针对表的每一行数据，数据量一多，锁定内容就多，故开销大。但因它颗粒度小，锁定行不会影响到别的行。所以并发就高。而如果表锁在一个入口就卡死了，那整体申请解决必定就会降落。

面试官： 我记得行锁外面有几种不同的实现形式，你晓得吗？

您可真贴心啊，替我思考这么多，大佬都是这么心比针细？我要是说不晓得，你老是不是又筹备给出穿小鞋啦。强忍心田啃人的激动

ps: 读懂图，阐明你有故事

吒吒辉： innodb 虽反对行锁，但锁实现的算法却和 SQL 的查问模式有关系：

• Record Lock（记录锁）：单个行记录上的锁。也就是咱们日常认为的行锁。由

`
where =
`
的模式触发

• Gap Lock（间隙锁）：间隙锁，锁定一个范畴，但不包含记录自身（它锁住了某个范畴内的多个行，包含基本不存在的数据）。

GAP 锁的目标，是为了避免事务插入而导致幻读的状况。该锁只会在隔离级别是 RR 或者以上的级别内存在。间隙锁的目标是为了让其余事务无奈在间隙中新增数据。SQL 外面用 where >、>= 等范畴条件触发，但会依据锁定的范畴内，是否蕴含了表中实在存在的记录进行变动，如果存在实在记录就会进化为 临建锁。反之就为间隙所。

• Next-Key Lock（临键锁）：它是记录锁和间隙锁的联合，锁定一个范畴，并且锁定记录自身。对于行的查问，都是采纳该办法，次要目标是解决幻读的问题。next-key 锁是 InnoDB 默认的。是一个左开右闭的规定
• IS 锁：动向共享锁、Intention Shared Lock。当事务筹备在某条记录上加 S（读）锁时，须要先在表级别加一个 IS 锁。
• IX 锁：动向排它锁、Intention Exclusive Lock。当事务筹备在某条记录上加 X（写）锁时，须要先在表级别加一个 IX 锁。

面试官： 那这个货色是怎么实现的？

t(id PK, name KEY, sex, flag);

表中有四条记录：

1, zhazhahui, m, A

3, nezha, m, A

5, lisi, m, A

9, wangwu, f, B

• 记录锁

select * from t where id=1 for update;
锁定 id = 1 的记录

• 间隙锁

select * from t where id > 3 and id < 9 ;

锁定(3,5]，（5，9）范畴的值，因为以后拜访 3 到 9 的范畴记录，就须要锁定表外面曾经存在的数据来解决幻读和不可反复读的问题

• 临建锁

select * from t where id >=9 ;

会锁定 [9,+∞)。查问会先选中 9 号记录，所以锁定范畴就以 9 开始到正无穷数据。

面试官： 那动向排它、共享锁呢？是怎么个内容

吒吒辉： 动向排它锁和动向共享锁，是针对以后 SQL 申请拜访数据行时，会提前进行申请拜访，如果最终行锁未命中就会进化为该 类型 的表锁。

面试官： 那有这个动向排它锁有什么益处呢？

吒吒辉： 可提前做预判，每次尝试获取行锁之前会查看是否有表锁，如果存在就不会持续申请行锁，从而缩小锁的开销。从而整个表就进化为表锁。

面试官： 那你入手给我演示下每个场景

嗯。。。（瞳孔放大 2 倍）我这不说的很明确吗？
难道成心和作对，这是干嘛啊。欺侮人嘛不是
只见那面试官突然翘起来二郎腿，还有节奏的抖动着腿，看向我。一看就是抖音整多了
哎，没方法 官大以及压死人。打碎了牙齿本人咽。你给我看细细看好了，最好眼睛都别眨

吒吒辉： 因为锁就是解决事务并发的问题，所以记录锁就不演示了，间接游荡在间隙和临建锁外面。

建设语句：

CREATE TABLE `t1` (`id` int(10) NOT NULL AUTO_INCREMENT,
  `name` varchar(64) COLLATE utf8mb4_general_ci DEFAULT NULL,
  `age` tinyint(3) unsigned DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

表数据：

间隙锁：

• 敞开 MySQL 默认的事务主动提交机制。

  • 敞开前：

• 敞开后：

加锁：

直接插入 >8 的数据就阻塞，都会上锁。为的就解决插入新数据而导致幻读。

【啊！幻读不晓得呀。下篇文章给大家安顿上】

面试官： 你这条件不是 >= 8 吗？那等于 8 呢？被吃辣？

吒吒辉： 别着急嘛，这不还没说完吗。为什么不指定 8 呢？

因为 >=8 的条件会从 间隙锁降级为临建锁，因为你条件外面蕴含了 8 这个实在存在的数据。所以会把它锁起来。如下：

所以，最终的行锁会和 SQL 语句的条件触发有关系，一旦范畴查问蕴含了数据库外面实在存在数据，就会降级为临建锁。不要问我为什么？看后面的定义

面试官独白：这小伙多少看来还有有点货，不错。此刻面试官露出一丝笑容。殊不知他心田又开酝酿起了新的想法。就等我入瓮

面试官： 那什么场景上行锁不会失效呢？锁 锁定的又是什么？

此刻，我呆了，这都什么跟什么啊。不带这么玩的吧。天杀的，净使坏

锁的触发机制

吒吒辉：
innodb 的行锁是依据索引触发，如果没有相干的索引，那行锁将会进化成表锁（即锁定整个表里的行）。
而 锁 锁定的是 索引 即索引树外面的数据库字段的值。

• id 为主键索引字段。

• 给 age 字段上锁

• age 字段没索引，进化成表锁。间接查问将失败。

有索引，用索引字段查问可得数据，其余字段查问将失败。因为获取不到行锁，只能期待。而锁定的是索引，故此其它用其它索引值查问能拿查问数据

• 索引字段上锁

• 索引以后字段锁定，用其余索引字段可查问

• 不是索引字段都差不到。

面试官： 你后面说到的锁能够解决事务并发，然而 MVCC 也是用于解决并发，那干嘛还用锁来呢？你给说说

吒吒辉： 通过 MVCC 能够解决脏读、不可反复读、幻读这些读一致性问题，但实际上这只是解决了一般 select 语句的数据读取问题。
事务利用 MVCC 进行的读取操作称之为快照读，所有一般的 SELECT 语句在 READ COMMITTED、REPEATABLE READ 隔离级别下都算是快照读。

除了快照读之外，还有一种是 锁定读 ，即在读取的时候给记录加锁，在 锁定读 的状况下仍然要解决脏读、不可反复读、幻读的问题。

比方：如果 1 4 7 9 的数据。如果条件为 where > 4 的，那如果不锁定到（4，7] (7,9],(9，+∞）。那势必就会早幻读，不可反复读的问题。

ps: 不反复读？脏读是如何产生的？

死锁

面试官： 那你说下数据库的死锁是个什么状况？

吒吒辉： 死锁是指两个或多个事务在同一资源上互相占用，并申请锁定对方占用的资源，从而导致恶性循环。

当事务试图以不同的程序锁定资源时，就可能产生死锁。多个事务同时锁定同一个资源时也可能会产生死锁。

个别可通过死锁检测和死锁超时机制来解决该问题。
死锁查看：
像 InnoDB 存储引擎，就能检测到死锁的循环依赖，并立刻返回一个谬误。否则死锁会导致呈现十分慢的查问。通过参数 innodb_deadlock_detect 设置为 on，来开启。

超时机制：
就是当查问的工夫达到锁期待超时的设定后放弃锁申请。InnoDB 目前解决死锁的办法是，将持有起码行级排他锁的事务进行回滚（这是绝对比较简单的死锁回滚算法)。

可通过配置参数 innodb_lock_wait_timeout 用来设置超时工夫。如果有些用户应用哪种大事务，就设置 锁超时工夫大于事务执行工夫 。
但这种状况下死锁超时查看的发现工夫是无奈承受的。

面试官： 那你说说 InnoDB 和 MyisAM 是如何发现死锁的？

吒吒辉：

• innodb

数据库会把事务单元锁维持的锁和它所期待的锁都记录下来，Innodb 提供了 wait-for graph 算法来被动进行死锁检测，每当加锁申请无奈立刻满足需要进入期待时，wait-for graph 算法都会被触发。当数据库检测到两个事务不同方向地给同一个资源加锁（产生循序），它就认为产生了死锁，触发 wait-for graph 算法。

比方：事务 1 给 A 加锁，事务 2 给 B 加锁，同时事务 1 给 B 加锁（期待），事务 2 给 A 加锁就产生了死锁。那么死锁解决办法就是终止一边事务的执行即可，这种效率一般来说是最高的，也是支流数据库采纳的方法。

Innodb 目前解决死锁的办法就是 将持有起码行级排他锁的事务进行回滚。这是绝对比较简单的死锁回滚形式。死锁产生当前，只有局部或者齐全回滚其中一个事务，能力突破死锁。

对于事务型的零碎，这是无奈防止的，所以应用程序在设计必须思考如何解决死锁。大多数状况下只须要从新执行因死锁回滚的事务即可。

• MyisAM

MyisAM 本身只反对表级锁，故加锁后一次性获取的。所以资源上不会呈现多个事务之间相互须要对方开释锁之后再来进行解决。故不会有死锁

面试官： wait-for graph 算法怎么了解？

吒吒辉： 如下所示，四辆车就是死锁

它们互相期待对方的资源，而且造成环路！每辆车可看为一个节点，当节点 1 须要期待节点 2 的资源时，就生成一条有向边指向节点 2，最初造成一个有向图。咱们只有检测这个有向图是否呈现环路即可，呈现环路就是死锁！这就是 wait-for graph 算法。

Innodb 将各个事务看为一个个节点，资源就是各个事务占用的锁，当事务 1 须要期待事务 2 的锁时，就生成一条有向边从 1 指向 2，最初行成一个有向图。

面试官： 既然死锁无奈防止，那如何缩小产生呢？

吒吒辉：

• 对应用程序进行调整 / 批改。某些状况下，你能够通过把大事务分解成多个小事务，使得锁可能更快被开释，从而极大水平地升高死锁产生的频率。在其余状况下，死锁的产生是因为两个事务采纳不同的程序操作了一个或多个表的雷同的数据集。须要改成以雷同程序读写这些数据集，换言之，就是对这些数据集的拜访采纳串行化形式。这样在并发事务时，就让死锁变成了锁期待。
• 批改表的 schema，例如：删除外键束缚来拆散两张表，或者增加索引来缩小扫描和锁定的行。
• 如果产生了间隙锁，你能够把会话或者事务的事务隔离级别更改为 RC(read committed)级别来防止，能够防止掉很多因为 gap 锁造成的死锁，但此时须要把 binlog_format 设置成 row 或者 mixed 格局。
• 为表增加正当的索引，不走索引将会为表的每一行记录增加上锁（等同表锁），死锁的概率大大增大。
• 为了在单个 InnoDB 表上执行多个并发写入操作时防止死锁，能够在事务开始时通过为预期要批改的每个元祖（行）应用 SELECT … FOR UPDATE 语句来获取必要的锁，即便这些行的更改语句是在之后才执行的。
• 通过 SELECT … LOCK IN SHARE MODE 获取行的读锁后，如果以后事务再须要对该记录进行更新操作，则很有可能造成死锁。因进行获锁读取在批改

这时，只见对面所坐面试官，捋了捋那没有毛发的下巴，故作三思而行，像是在打量这什么。难道 难道 是让我通过了吗？
此刻心田犹如小鹿乱撞，呐喊到我要干它二量。真的是不容易。就在此时，他起身而立，那红色 T 桖衫包裹着那甩大肚子，犹如波浪高低翻滚。一看就是没少在酒桌上撸肉。

只见闭口到，小伙子不错啊。

这是必定我吗？不容易啊，明天不开几把 LOL，难消我心头之恨

面试官： 其实这数据库嘛，内容还是有很多的，你回去筹备下，下一次的面试吧

。。。。什么个玩意儿，下次？那就是这次不行啦，这还没考够啊，下巴原本没毛，你捋个什么劲儿，整得个神神忽忽的。此时心田犹如排山倒海，猛龙过江。白鹤亮翅的激动打他，奈何我这小身板子不行

吒吒辉： 那行吧，下次是多久啊，我这好多天都没整顿好的啦，你给我个准信呗。

我用那水汪汪可怜的小眼神望向他说到。他却很斯文的笑着，说道

面试官： 快了，小伙子别着急，我看好你的，加油

我加你那撸啊丝压迫花生油。面个试，还嫌我脸上出油出的不多，都是被你挤出来的。只有强忍住心田的激动。哎 官大一级压死人啊
吒吒辉： 行吧，那我走啦
此刻，露出我那兴冲冲的背影，犹如鲁迅学生笔下的孔乙己

参考：《高性能 MySQL》https://zhuanlan.zhihu.com/p/29150809
https://www.cnblogs.com/yulibostu/articles/9978618.html

如有帮忙，欢送点赞关注分享额，微信搜寻【莲花童子哪吒】获取体系化内容，加我纳入群聊，一起交流学习提高晋升。