MySQLInnoDB的select和update形成表级锁实例分析

这篇文章主要介绍了MySQL InnoDB的select和update形成表级锁实例分析的相关知识，内容详细易懂，操作简单快捷，具有一定借鉴价值，相信大家阅读完这篇MySQL InnoDB的select和update形成表级锁实例分析文章都会有所收获，下面我们一起来看看吧。

成都创新互联服务项目包括江口网站建设、江口网站制作、江口网页制作以及江口网络营销策划等。多年来，我们专注于互联网行业，利用自身积累的技术优势、行业经验、深度合作伙伴关系等，向广大中小型企业、政府机构等提供互联网行业的解决方案，江口网站推广取得了明显的社会效益与经济效益。目前，我们服务的客户以成都为中心已经辐射到江口省份的部分城市，未来相信会继续扩大服务区域并继续获得客户的支持与信任！

InnoDB 的细粒度行锁以及事务支持一度是 MySQL 最吸引人的特性之二。但是在多种情况下，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 表：

表中有四条记录：

从上图中可以看到：

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

• 第二幅图，name上的普通索引，叶子存储了PK的值；

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

1. 会先在 name 普通索引上查询到PK=1；

2. 再在聚集索引衫查询到(1,shenjian, m, A)的行记录；

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

关于“MySQL InnoDB的select和update形成表级锁实例分析”这篇文章的内容就介绍到这里，感谢各位的阅读！相信大家对“MySQL InnoDB的select和update形成表级锁实例分析”知识都有一定的了解，大家如果还想学习更多知识，欢迎关注创新互联行业资讯频道。