linux select读取节点数据失败_【精选面试题】数据库系列

点击上方蓝字  关注我们

一、mysql 聚集索引、非聚集索引

聚集索引：

给表上了主键，那么表在内存上的由整齐排列的结构转变成了树状结构，也就是「平衡树」结构，换句话说，就是整个表就变成了一个索引。没错， 再说一遍， 整个表变成了一个索引，也就是所谓的「聚集索引」。这就是为什么一个表只能有一个主键， 一个表只能有一个「聚集索引」，因为主键的作用就是把「表」的数据格式转换成「索引(平衡树)」的格式放置。

非聚集索引：

非聚集索引和聚集索引一样， 同样是采用平衡树作为索引的数据结构。索引树结构中各节点的值来自于表中的索引字段， 假如给user表的name字段加上索引 ， 那么索引就是由name字段中的值构成，在数据改变时， DBMS需要一直维护索引结构的正确性。如果给表中多个字段加上索引 ， 那么就会出现多个独立的索引结构，每个索引(非聚集索引)互相之间不存在关联。

区别在于，通过聚集索引可以查到需要查找的数据， 而通过非聚集索引可以查到记录对应的主键值 ， 再使用主键的值通过聚集索引查找到需要的数据。

总结：

非聚集索引就是一般常用的索引，索引树的根节点是表的主键；聚集索引就是主键组成的树，根节点是数据库真实数据的位置。许多数据库的文档会告诉读者：聚集索引按照顺序物理的存储数据到磁盘。但是试想下，如果聚集索引必须按照特定顺序存放物理记录，则维护成本显得非常高。所以，聚集索引的磁盘存储并不是物理上连续的，而是逻辑上连续。

二、mysql 索引为什么会选择B+树存储实现

概念：

mysql底层使用的是B+树，mysql索引是放在磁盘上面的，因此每次读取索引时通过IO从磁盘读取。

１、hash索引：无规则、不能排序

２、二叉树：解决hash索引不能排序问题，但是当数据有序时会出现线性排列，树的深度会变得很深，会消耗大量IO。

3、平衡二叉树：解决二叉树数据有序时出现的线性插入树太深问题，树的深度会明显降低，极大提高性能，但是当数据量很大时，一般mysql中一张表达到3-5百万条数据是很普遍的，因此平衡二叉树的深度还是非常大，mysql读取时还是会消耗大量IO，不仅如此，计算从磁盘读取数据时以页(4KB)为单位的,及每次读取4096byte。平衡二叉树每个节点只保存了一个关键字(如int即4byte)，浪费了4092byte，极大的浪费了读取空间。

4、B-树：解决平衡二叉树树深度的问题，解决了平衡二叉树读取消耗大量内存空间的问题。因为B-树每个节点可以存放多个关键字，最大限度的利用了从磁盘读取的内存空间，单节点存放多个关键字同时也大大减少了树的深度。极大的提高了mysql的查询性能。但是B-树还是有缺点，B-树对有范围查找的查询(如age>20)时采用的还是中序排序法，因此也需要多遍历，并且查询性能不稳定，比如查询(select * from table where id = 222 和 select * from table where id = 223)时在查询效率(耗时)上可能会存在一定的差别，因为B-树还是将关键字，这里为id，存放在根节点和叶节点的，如果运气好，可能id=222这个关键字就在第一个节点，消耗一次IO就找到了，而id=223可能在叶节点，需要消耗3次IO才能找到。因此B-树对同一条sql语句的查询性能可能会有很大影响(确实感觉有点扯，但是事实是这样)。

5、B+树：将关键字全部存放在叶子节点(查询更稳定，同一条mysql语句执行效率时相同的，都会消耗3次IO)，将相邻叶子节点的地址保存起来(相比于B-树，对于mysql的范围查找不用再使用中序查找，而是可以直接快读获取到。)

B+树是B-树的变种(PLUS版)多路绝对平衡查找数，他拥有B-树的优势。

B+树扫库、表能力更强(因为B+树只在叶子节点保存数据了，因此每次IO读取的数据会更多。)

B+树的磁盘读写能力更强(因为B+树只在叶子节点保存数据了，因此每次IO读取的数据会更多。)

B+树的排序能力更强。(因为叶子节点添加了左边最大的指向右边最小的，有天然的排序。)

B+树的查询效率更加稳定。(B-树可能一次IO就命中查询，但是同一类查询，不同的值可能一次IO就命中、可能3次IO才命中，查询效率不稳定。而B+树IO消耗次数是固定的，因此叶子节点才保存数据地址，更加稳定。)

三、mysql 执行计划

1.执行计划的概念：

我们都知道mysql对于一条sql在执行过程中会对它进行优化，而对于查询语句的来说最好的优化方案就是使用索引。而执行计划就是显示mysql执行sql时的详细执行情况。其中包含了是否使用索引，使用了哪些索引…

2.执行计划的语法：

• 常规执行计划语法