MySQL InnoDB存储引擎select和update查询阻塞insert语句,形成表级锁

​

大约在两个月前，有同事在使用 Select 查询语句的时候，发现整张表被锁了，导致日志中经常出现 time out 异常。当时我判断是 select 不可能锁表的，而且更不可能锁整张表。直到今天我抽出时间查询资料，才发现不仅 Select 会锁整张表，Update 和 delete 都会锁整张表，这里面的原因且听本文分解！

InnoDB 的细粒度行锁以及事务支持一度是 MySQL 最吸引人的特性之二。但是在多种情况下，InnoDB 的行级锁会变成表级锁。使用不当，给我们带来的危害极大！

如果 InnoDB 的查询没有命中索引，也将退化为表锁。InnoDB 的细粒度锁，是实现在索引记录上的。

InnoDB 的索引

InnoDB 的索引有两类。聚集索引(Clustered Index)与普通索引(Secondary Index)。

InnoDB 的每一个表都会有聚集索引。如果你没手动创建，InnoDB 也会默认的帮你创建聚集索引。

聚集索引以下面三种形式存在：

1. 如果表定义了 PK，则 PK 就是聚集索引；
2. 如果表没有定义 PK，则第一个非空 unique 列是聚集索引；
3. 否则，InnoDB 会创建一个隐藏的 row-id 作为聚集索引。

我们知道索引的结构是 B+ 树，这里不展开 B+ 树的细节，先说几个结论：

1. 在索引结构中，非叶子节点存储 key，叶子节点存储 value；
2. 聚集索引，叶子节点存储行记录(row)；
3. 普通索引，叶子节点存储了 PK 的值。

由于上面我们说过的 InnoDB 的每一个表都会有聚集索引，索引结构中叶子节点存储 value，而聚集索引的叶子节点还会存储行记录(row)。所以，InnoDB 索引和记录是存储在一起的，而 MyISAM 的索引和记录是分开存储的。

所以，InnoDB 的普通索引，实际上会扫描两遍：第一遍，由普通索引找到 PK；第二遍，由PK找到行记录；

关于索引结构，我这里不展开去讲，后面我查询更多资料后，将给大家详细的讲讲 InnoDB/MyISAM 的索引结构，如果大家感兴趣的话。

下面我们通过一个例子来说明。假设存在一个下面结构的 InnoDB 表：

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

表中有四条记录：

1, shenjian, m, A
3, zhangsan, m, A
5, lisi, m, A
9, wangwu, f, B

从上图中可以看到：

• 第一幅图，id PK的聚集索引，叶子存储了所有的行记录；
• 第二幅图，name上的普通索引，叶子存储了PK的值；

当执行查询 select * from t where name=’shenjian’; 语句时，会发生下面的过程：

1. 会先在 name 普通索引上查询到PK=1；
2. 再在聚集索引衫查询到(1,shenjian, m, A)的行记录；

​

再回到文章开头部分，我们说过“InnoDB 的查询没有命中索引，也将退化为表锁。InnoDB 的细粒度锁，是实现在索引记录上的。”由于这里的 name 并没有创建索引，所以它会变成表锁。至于时读锁和写锁，它们都是锁。InnoDB 的锁，与索引类型，事务的隔离级别相关。InnoDB 一共有 7 种锁，后面有时间了等我查资料，我们再一起来学习