mysql索引内部达成与算法分析
发布时间：2021-12-20 14:30:03 所属栏目：MySql教程 来源：互联网
导读：本篇内容主要讲解mysql索引内部实现与算法分析，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习mysql索引内部实现与算法分析吧! 存储引擎从索引的根节点开始进行搜索，通过节点槽中的指针向下层查找，比较节点页的
|
本篇内容主要讲解“mysql索引内部实现与算法分析”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“mysql索引内部实现与算法分析”吧! 存储引擎从索引的根节点开始进行搜索，通过节点槽中的指针向下层查找，比较节点页的值和要查找的值找到合适的指针进入下层子节点。存储引擎最终要么找到对应的值，要么该记录不存在。 叶子节点的指针指向的是被索引的数据，而不是其他的节点页 索引可以按值查找之外，还可以用于查询中的order by操作(原因：索引树中的节点是有序的) B+tree索引的限制： 1.如果不是按照索引的最左列开始查找，则无法使用索引 2.不能跳过索引中的列 3.如果查询中有某个列的范围查找，则其右边所有列都无法使用索引优化查找 B+树的插入操作 B+树的插入必须保证插入后叶节点中的记录依然排序， 插入B+树的三种情况 第一种情况，往图中插入28，leaf page和index page都没有满，直接插入 第二种情况，往图中插入70，leaf page满了，index page没有满 说明：采用旋转操作使得其减少一次页的拆分操作 第三种情况，在图中插入95，leaf page和index page都满了 说明：B+树为了保持平衡，对新插入的键值可能需要大量的拆分页操作，但是B+树主要用于磁盘，我们应该尽可能减少页的拆分，可以通过旋转功能（leaf page已经满了，但是左右兄弟节点没有满） B+树的删除操作 B+树使用填充因子来控制树的删除变化，50%是填充因子可设的最小资。同样必须保证删除后叶节点中的记录依然排序。 删除B+树（根据填充因子的变化来衡量）的三种情况 在图中删除70 在图中删除25，此时25的兄弟节点的28更新到page index中 在图中删除60，此时填充因子小于50%，需要做合并操作 B+树索引 B+树索引本质是在B+树在数据库中的实现 特点：扇出性 数据库中B+树索引分为：聚集索引（clustered index）、辅助聚集索引（secondary index） 索引组织表：表中数据按照主键顺序存放 堆表：按照插入数据顺序存放，堆表上的索引都是非聚集的，且堆表没有主键 聚集索引(每张表只有一个):按照每张表的主键构造一棵B+树，且叶节点存放着整张表的行记录数据，所以聚集索引的叶节点也成了数据页， 辅助聚集索引的叶节点上存放的仅仅是键值以及指向数据页的偏移量，不是一个完整行记录 聚集索引不是一种单独的索引类型，而是一种数据存储方式。innodb的聚集索引实际上在同一个结构中保存了B+tree索引和数据行。 当表有聚集索引时，数据行实际上是存储在索引的叶子页中 说明：聚集索引的存储在物理上是不连续的，在逻辑上是连续的：1.页通过双向链表链接，页按照主键的顺序排序；2.每个页中的记录也是通过双向链表进行维护，物理存储上可以同样不按照主键存储 聚集索引的优点： 可以把相关数据保存在一起 数据访问更快(聚集索引将索引和数据保存在同一个b+tree中) 使用覆盖索引扫描的查询可以直接使用页节点中的主键值 聚集索引的缺点： 聚集数据提高了IO性能，如果数据全部放在内存中，则访问的顺序就没那么重要了 插入速度严重依赖插入顺序。按主键的顺序插入是速度最快的。但如果不是按照主键顺序加载数据，则需在加载完成后最好使用optimize table重新组织一下表 辅助索引：叶节点包含键值，且每个叶级别的索引行还包含一个书签（相应行数据的聚集索引） 辅助索引和聚集索引的关系图 说明：辅助索引的存在不影响数据在聚集索引中的组织，所以每张表可以有多个辅助索引 原理：通过辅助索引来寻找数据时过程：innodb会遍历辅助索引并通过叶级别的指针获得指向主键索引的主键，然后再通过主键索引来找到一个完整的行记录。 B+树索引的管理 索引的创建和删除的方法：alter table；create /drop index 创建主键索引过程：先创建一张新的临时表，然后将数据导入临时表，删除原表，再把临时表重名为原来的表名 创建辅助索引过程：在创建过程中不需要重建表，只会对表加上一个S锁，速度极快。 通过show index from table_name可以查看表中索引的信息 说明： table：索引所在的表名 Non_unique:非唯一索引，primary key是0 Key_name:索引的名称 Seq_in_index:索引中该列的位置 Column_name：索引的列 Collation:列以什么方式存储在索引中，B+树索引总是A，即排序；如果使用了heap存储引擎，且建立了hash索引，就会显示NULL，因为hash通过hash桶来存放索引数据，而不是对数据进行排序 Cardinality:表示索引中唯一值的数目的估计值，Cardinality/表的行数 尽可能接近1，太小则需要重建该索引 Sub_part:是否是列的部分被索引，如只索引某一列的前多少字符，如果索引整个列，则该字段为NULL packed：关键字如何被压缩。没有被压缩则为NULL NULL：是否索引的列含有null值， Index_type:索引的类型，innodb只支持B+索引 comment:注释 B+树索引的使用 当访问高选择性字段并从表中取出很少一部分行时，就需要对这个字段添加B+树索引 注：当取出数据量超过表中数据的20%，优化器就不会使用索引，而是进行全表的扫表。且预估的返回行数的值是不准确的 （编辑：站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
