MySQL行锁、表锁、间隙锁，你都了解吗

前言

咱们前几篇讲了索引是什么，如何使用explain分析索引使用状况，如何去优化索引，以及show profiles分析SQL语句执行资源消耗的学习。今天咱们来说讲MySQL的各类锁，这里存储引擎咱们使用InnoDB

准备工做

建立表 tb\_innodb\_lock

`drop table if exists test_innodb_lock;`
`CREATE TABLE test_innodb_lock (`
 `a INT (11),`
 `b VARCHAR (20)`
`) ENGINE INNODB DEFAULT charset = utf8;`
`insert into test_innodb_lock values (1,'a');`
`insert into test_innodb_lock values (2,'b');`
`insert into test_innodb_lock values (3,'c');`
`insert into test_innodb_lock values (4,'d');`
`insert into test_innodb_lock values (5,'e');`

建立索引

`create index idx_lock_a on test_innodb_lock(a);`
`create index idx_lock_b on test_innodb_lock(b);`

MySQL 各类锁演示

• 先将自动提交事务改为手动提交：set autocommit=0;
• 咱们启动两个会话窗口 A 和 B，模拟一个抢到锁，一个没抢到被阻塞住了。

行锁（写&读）

• A 窗口执行

`update test_innodb_lock set b='a1' where a=1;`

``````
`SELECT * from test_innodb_lock;`

咱们能够看到 A 窗口能够看到更新后的结果

• B 窗口执行

`SELECT * from test_innodb_lock;`

咱们能够看到 B 窗口不能看到更新后的结果，看到的仍是老数据，这是由于 a = 1 的这行记录被 A 窗口执行的 SQL 语句抢到了锁，而且没有执行 commit 提交操做。因此窗口 B 看到的仍是老数据。这就是 MySQL 隔离级别中的"读已提交"。

• 窗口 A 执行 commit 操做

`COMMIT;`

• 窗口 B 查询

`SELECT * from test_innodb_lock;`

这个时候咱们发现窗口 B 已经读取到最新数据了

行锁（写&写）

• 窗口 A 执行更新 a = 1 的记录

`update test_innodb_lock set b='a2' where a=1;`

这时候并无 commit 提交，锁是窗口 A 持有。

• 窗口 B 也执行更新 a = 1 的记录

`update test_innodb_lock set b='a3' where a=1;`

能够看到，窗口 B 一直处于阻塞状态，由于窗口 A 尚未执行 commit，还持有锁。窗口 B 抢不到 a = 1 这行记录的锁，因此一直阻塞等待。

• 窗口 A 执行 commit 操做

`COMMIT;`

• 窗口 B 的变化

能够看到这个时候窗口 B 已经执行成功了

表锁

当索引失效的时候，行锁会升级成表锁，索引失效的其中一个方法是对索引自动 or 手动的换型。a 字段自己是 integer，咱们加上引号，就变成了 String，这个时候索引就会失效了。

• 窗口 A 更新 a = 1 的记录

`update test_innodb_lock set b='a4' where a=1 or a=2;`

• 窗口 B 更新 a = 2 的记录

`update test_innodb_lock set b='b1' where a=3;`

这个时候发现，虽然窗口 A 和 B 更新的行不同，可是窗口 B 仍是被阻塞住了，就是由于窗口 A 的索引失效，致使行锁升级成了表锁，把整个表锁住了，索引窗口 B 被阻塞了。

• 窗口 A 执行 commit 操做

`COMMIT;`

• 窗口 B 的变化

能够看到这个时候窗口 B 已经执行成功了

间隙锁

• 什么是间隙锁

当咱们采用范围条件查询数据时，InnoDB 会对这个范围内的数据进行加锁。好比有 id 为：一、三、五、7 的 4 条数据，咱们查找 1-7 范围的数据。那么 1-7 都会被加上锁。二、四、6 也在 1-7 的范围中，可是不存在这些数据记录，这些 二、四、6 就被称为间隙。

• 间隙锁的危害

范围查找时，会把整个范围的数据所有锁定住，即使这个范围内不存在的一些数据，也会被无辜的锁定住，好比我要在 一、三、五、7 中插入 2，这个时候 1-7 都被锁定住了，根本没法插入 2。在某些场景下会对性能产生很大的影响

• 间隙锁演示

咱们先把字段 a 的值修改为 一、三、五、七、9

• 窗口 A 更新 a = 1~7 范围的数据

`update test_innodb_lock set b='b5' where a>1 and a<7;`

• 窗口 B 在 a = 2 的位置插入数据

`insert into test_innodb_lock values(2, "b6");`

这个时候发现窗口 B 更新 a = 2 的操做一直在等待，由于 1~7 范围的数据被间隙锁，锁住了。只有等窗口 A 执行 commit，窗口 B 的 a = 2 才能更新成功

行锁分析

• 执行 SQL 分析命令

`show status like 'innodb_row_lock%';`

• Variable\_name 说明
• Innodb\_row\_lock\_current\_waits：当前正在等待锁定的数量。
• Innodb\_row\_lock\_time：从系统启动到如今锁定的时长。
• Innodb\_row\_lock\_time\_avg：每次等待锁所花平均时间。
• Innodb\_row\_lock\_time\_max：从系统启动到如今锁等待最长的一次所花的时间。
• Innodb\_row\_lock\_waits：系统启动后到如今总共等待锁的次数。

结语

你们能够根据 Variable\_name 这几个参数考虑是否要进行优化，若是锁定时间，锁定次数过大，那就该考虑优化了。优化手段能够参考以前索引优化的文章。

IT 老哥