标签：insert 存储 聚集 update 查询 索引 InnoDB PK
大约在两个月前，有同事在使用 Select 查询语句的时候，发现整张表被锁了，导致日志中经常出现 time out 异常。当时我判断是 select 不可能锁表的，而且更不可能锁整张表。直到今天我抽出时间查询资料，才发现不仅 Select 会锁整张表，Update 和 delete 都会锁整张表，这里面的原因且听本文分解！
InnoDB 的细粒度行锁以及事务支持一度是 MySQL 最吸引人的特性之二。但是在多种情况下，InnoDB 的行级锁会变成表级锁。使用不当，给我们带来的危害极大！
如果 InnoDB 的查询没有命中索引，也将退化为表锁。InnoDB 的细粒度锁，是实现在索引记录上的。
InnoDB 的索引有两类。聚集索引(Clustered Index)与普通索引(Secondary Index)。
InnoDB 的每一个表都会有聚集索引。如果你没手动创建，InnoDB 也会默认的帮你创建聚集索引。
聚集索引以下面三种形式存在：
-
如果表定义了 PK，则 PK 就是聚集索引；
-
如果表没有定义 PK，则第一个非空 unique 列是聚集索引；
- 否则，InnoDB 会创建一个隐藏的 row-id 作为聚集索引。
我们知道索引的结构是 B+ 树，这里不展开 B+ 树的细节，先说几个结论：
-
在索引结构中，非叶子节点存储 key，叶子节点存储 value；
-
聚集索引，叶子节点存储行记录(row)；
- 普通索引，叶子节点存储了 PK 的值。
由于上面我们说过的 InnoDB 的每一个表都会有聚集索引，索引结构中叶子节点存储 value，而聚集索引的叶子节点还会存储行记录(row)。所以，InnoDB 索引和记录是存储在一起的，而 MyISAM 的索引和记录是分开存储的。
所以，InnoDB 的普通索引，实际上会扫描两遍：第一遍，由普通索引找到 PK；第二遍，由PK找到行记录；
关于索引结构，我这里不展开去讲，后面我查询更多资料后，将给大家详细的讲讲 InnoDB/MyISAM 的索引结构，如果大家感兴趣的话。
下面我们通过一个例子来说明。假设存在一个下面结构的 InnoDB 表：
1
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’; 语句时，会发生下面的过程：
-
会先在 name 普通索引上查询到PK=1；
- 再在聚集索引衫查询到(1,shenjian, m, A)的行记录；
再回到文章开头部分，我们说过“InnoDB 的查询没有命中索引，也将退化为表锁。InnoDB 的细粒度锁，是实现在索引记录上的。”由于这里的 name 并没有创建索引，所以它会变成表锁。至于时读锁和写锁，它们都是锁。InnoDB 的锁，与索引类型，事务的隔离级别相关。InnoDB 一共有 7 种锁，后面有时间了等我查资料，我们再一起来学习！
最后，欢迎关注我的个人微信公众号：业余草（yyucao）！可加QQ1群：135430763，QQ2群：454796847，QQ3群：187424846。QQ群进群密码：xttblog，想加微信群的朋友，可以微信搜索：xmtxtt，备注：“xttblog”，添加助理微信拉你进群。备注错误不会同意好友申请。再次感谢您的关注！后续有精彩内容会第一时间发给您！原创文章投稿请发送至532009913@qq.com邮箱。商务合作可添加助理微信进行沟通！
标签：insert,存储,聚集,update,查询,索引,InnoDB,PK 来源： https://blog.51cto.com/15127565/2671203
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。