精华内容
下载资源
问答
  • 索引原理

    万次阅读 多人点赞 2019-06-12 07:51:29
    有兴趣的同学可以看原文~ 使用索引很简单,只要能写创建表的语句,就肯定...然而, 会使用索引是一回事, 而深入理解索引原理又能恰到好处使用索引又是另一回事,这完全是两个天差地别的境界(我自己也还没有达到...

    文章转载于:https://www.cnblogs.com/aspwebchh/p/6652855.html

    有兴趣的同学可以看原文~

           使用索引很简单,只要能写创建表的语句,就肯定能写创建索引的语句,要知道这个世界上是不存在不会创建表的服务器端程序员的。然而, 会使用索引是一回事, 而深入理解索引原理又能恰到好处使用索引又是另一回事,这完全是两个天差地别的境界(我自己也还没有达到这层境界)。很大一部份程序员对索引的了解仅限于到“加索引能使查询变快”这个概念为止。

    • 为什么要给表加上主键?

    • 为什么加索引后会使查询变快?

    • 为什么加索引后会使写入、修改、删除变慢?

    • 什么情况下要同时在两个字段上建索引?

           这些问题他们可能不一定能说出答案。知道这些问题的答案有什么好处呢?如果开发的应用使用的数据库表中只有1万条数据,那么了解与不了解真的没有差别, 然而, 如果开发的应用有几百上千万甚至亿级别的数据,那么不深入了解索引的原理, 写出来程序就根本跑不动,就好比如果给货车装个轿车的引擎,这货车还能拉的动货吗?

           接下来就讲解一下上面提出的几个问题,希望对阅读者有帮助。

           网上很多讲解索引的文章对索引的描述是这样的「索引就像书的目录, 通过书的目录就准确的定位到了书籍具体的内容」,这句话描述的非常正确, 但就像脱了裤子放屁,说了跟没说一样,通过目录查找书的内容自然是要比一页一页的翻书找来的快,同样使用的索引的人难到会不知道,通过索引定位到数据比直接一条一条的查询来的快,不然他们为什么要建索引。

           想要理解索引原理必须清楚一种数据结构「平衡树」(非二叉),也就是b tree或者 b+ tree,重要的事情说三遍:“平衡树,平衡树,平衡树”。当然, 有的数据库也使用哈希桶作用索引的数据结构 , 然而, 主流的RDBMS都是把平衡树当做数据表默认的索引数据结构的。

           我们平时建表的时候都会为表加上主键, 在某些关系数据库中, 如果建表时不指定主键,数据库会拒绝建表的语句执行。 事实上, 一个加了主键的表,并不能被称之为「表」。一个没加主键的表,它的数据无序的放置在磁盘存储器上,一行一行的排列的很整齐, 跟我认知中的「表」很接近。如果给表上了主键,那么表在磁盘上的存储结构就由整齐排列的结构转变成了树状结构,也就是上面说的「平衡树」结构,换句话说,就是整个表就变成了一个索引。没错, 再说一遍, 整个表变成了一个索引,也就是所谓的「聚集索引」。 这就是为什么一个表只能有一个主键, 一个表只能有一个「聚集索引」,因为主键的作用就是把「表」的数据格式转换成「索引(平衡树)」的格式放置。

             

     

           上图就是带有主键的表(聚集索引)的结构图。图画的不是很好, 将就着看。其中树的所有结点(底部除外)的数据都是由主键字段中的数据构成,也就是通常我们指定主键的id字段。最下面部分是真正表中的数据。 假如我们执行一个SQL语句:

           select * from table where id = 1256;

           首先根据索引定位到1256这个值所在的叶结点,然后再通过叶结点取到id等于1256的数据行。 这里不讲解平衡树的运行细节, 但是从上图能看出,树一共有三层, 从根节点至叶节点只需要经过三次查找就能得到结果。如下图

              

           假如一张表有一亿条数据 ,需要查找其中某一条数据,按照常规逻辑, 一条一条的去匹配的话, 最坏的情况下需要匹配一亿次才能得到结果,用大O标记法就是O(n)最坏时间复杂度,这是无法接受的,而且这一亿条数据显然不能一次性读入内存供程序使用, 因此, 这一亿次匹配在不经缓存优化的情况下就是一亿次IO开销,以现在磁盘的IO能力和CPU的运算能力, 有可能需要几个月才能得出结果 。如果把这张表转换成平衡树结构(一棵非常茂盛和节点非常多的树),假设这棵树有10层,那么只需要10次IO开销就能查找到所需要的数据, 速度以指数级别提升,用大O标记法就是O(log n),n是记录总树,底数是树的分叉数,结果就是树的层次数。换言之,查找次数是以树的分叉数为底,记录总数的对数,用公式来表示就是

                

           用程序来表示就是Math.Log(100000000,10),100000000是记录数,10是树的分叉数(真实环境下分叉数远不止10), 结果就是查找次数,这里的结果从亿降到了个位数。因此,利用索引会使数据库查询有惊人的性能提升。

           然而, 事物都是有两面的, 索引能让数据库查询数据的速度上升, 而使写入数据的速度下降,原因很简单的, 因为平衡树这个结构必须一直维持在一个正确的状态, 增删改数据都会改变平衡树各节点中的索引数据内容,破坏树结构, 因此,在每次数据改变时, DBMS必须去重新梳理树(索引)的结构以确保它的正确,这会带来不小的性能开销,也就是为什么索引会给查询以外的操作带来副作用的原因。

           讲完聚集索引 , 接下来聊一下非聚集索引, 也就是我们平时经常提起和使用的常规索引。

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

                   

           每次给字段建一个新索引, 字段中的数据就会被复制一份出来, 用于生成索引。 因此, 给表添加索引,会增加表的体积, 占用磁盘存储空间。

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

                

          不管以任何方式查询表, 最终都会利用主键通过聚集索引来定位到数据, 聚集索引(主键)是通往真实数据所在的唯一路径。

          然而, 有一种例外可以不使用聚集索引就能查询出所需要的数据, 这种非主流的方法 称之为「覆盖索引」查询, 也就是平时所说的复合索引或者多字段索引查询。 文章上面的内容已经指出, 当为字段建立索引以后, 字段中的内容会被同步到索引之中, 如果为一个索引指定两个字段, 那么这个两个字段的内容都会被同步至索引之中。

          先看下面这个SQL语句

          //建立索引

          create index index_birthday on user_info(birthday);

         //查询生日在1991年11月1日出生用户的用户名

         select user_name from user_info where birthday = '1991-11-1'

         这句SQL语句的执行过程如下

         首先,通过非聚集索引index_birthday查找birthday等于1991-11-1的所有记录的主键ID值

         然后,通过得到的主键ID值执行聚集索引查找,找到主键ID值对就的真实数据(数据行)存储的位置

         最后, 从得到的真实数据中取得user_name字段的值返回, 也就是取得最终的结果

         我们把birthday字段上的索引改成双字段的覆盖索引

         create index index_birthday_and_user_name on user_info(birthday, user_name);

         这句SQL语句的执行过程就会变为

         通过非聚集索引index_birthday_and_user_name查找birthday等于1991-11-1的叶节点的内容,然而, 叶节点中除了有user_name表主键ID的值以外, user_name字段的值也在里面, 因此不需要通过主键ID值的查找数据行的真实所在, 直接取得叶节点中user_name的值返回即可。 通过这种覆盖索引直接查找的方式, 可以省略不使用覆盖索引查找的后面两个步骤, 大大的提高了查询性能,如下图

             

           数据库索引的大致工作原理就是像文中所述, 然而细节方面可能会略有偏差,这但并不会对概念阐述的结果产生影响 。

    最后, 推荐三本关系数据库方面的书籍, 文中所讲解的概念内容都是来自于此。

         《SQL Server2005技术内幕之T-SQL查询》

           这本书虽然是针对SQL Server写的, 但是里面的大部份内容同样适用于其它关系数据库,此书对查询编写的技巧和优化讲解的非常透彻。

         《关系数据库系统概论》第四版

          王珊和萨师煊写的那本, 是大学计算机教材, 讲的通俗易懂, 在国内计算机书图书出版领域质量是排的上号的。

        《数据库系统概念》

          这本书在数据库领域非常出名, 被称之为帆船书, 书中内容博大精深,非一朝一夕可参透的。

    展开全文
  • mysql进阶(二十七)数据库索引原理

    万次阅读 2016-10-13 20:20:38
    mysql进阶(二十七)数据库索引原理前言  本文主要是阐述MySQL索引机制,主要是说明存储引擎Innodb。   第一部分主要从数据结构及算法理论层面讨论MySQL数据库索引的数理基础。   第二部分结合MySQL数据库中...

    #mysql进阶(二十七)数据库索引原理
    ##前言
      本文主要是阐述MySQL索引机制,主要是说明存储引擎Innodb。
      第一部分主要从数据结构及算法理论层面讨论MySQL数据库索引的数理基础。
      第二部分结合MySQL数据库中InnoDB数据存储引擎中索引的架构实现讨论聚集索引、非聚集索引及覆盖索引等话题。
      第三部分讨论MySQL中高性能使用索引的策略。
    ##一、数据结构及算法理论
      Innodb存储引擎实现索引的数据结构是B+树,下面介绍几种数据结构,一步步阐述为什么要使用B+树。
    ###1.1 B+树
      B+树索引的构造类似于二叉树,根据键值快速找到数据。但是B+树中的B不是代表二叉,而是代表平衡Balance。注意:B+树索引能找到的只是被查找数据行所在的页。然后数据库通过把页读入内存,再在内存中进行查找,最后查到数据。
      下面介绍二分查找法:将记录按有序化(递增或递减)排列,查找过程中采用跳跃式方式查找,例如:5、10、19、21、31、37、42、48、50、52这10个数,如图所示:

    ![这里写图片描述](https://img-blog.csdnimg.cn/img_convert/18c9629988d1f6b48043390a7946db8a.png)

       用了三次查找就能找到48。如果是顺序查找的话,则需要8次。对于上面10个数来说,顺序查找的平均查找次数为5.5次,而二分查找法为2.9次,在最坏的情况下,顺序查找的次数为10,而二分查找的次数为4。二分查找在Innodb中Page Directory中的槽是按照主键的顺序存放的,对于每一条具体记录的查询是通过对Page Directory进行二分查找。

    ###1.2二叉查找树

    ![这里写图片描述](https://img-blog.csdnimg.cn/img_convert/d41c33f5fb947d46105a2166d92970e1.png)

      数字代表每个节点的键值,二叉查找树中,左子树的键值总是小于根的键值,右子树的键值总是大于根的键值。通过中序遍历得到键值:2、3、5、6、7、8。
      二叉查找树的平均查找次数为2.3次。但是二叉查找树是可以任意构建,如构造如图:

    ![这里写图片描述](https://img-blog.csdnimg.cn/img_convert/b4b9a6835227be73678e8f3bda37c4af.png)

      但是这样跟顺序查找就差不多,所以就引用了平衡二叉树的思想,AVL树。
    ###1.3 AVL树
      定义:符合二叉查找树的定义,其次必须满足任何节点的左右两个子树的高度最大差为1。
    平衡二叉树虽然查找速度非常快但是维护一颗平衡二叉树的代价是非常大,通常需要1次或多次左旋和右旋来得到插入或更新后树的平衡性。
    ###1.4 B+树的特性

    ![这里写图片描述](https://img-blog.csdnimg.cn/img_convert/cfecfffc6a4c8164211397f06530d590.png)

      B+树是应文件系统而出的一种B树的变形树。在B树中,每一个元素在该树中只出现一次,有可能在叶子节点上,也有可能在分支节点上。而在B+树中,出现在分支节点的元素会被当作它们在该分支节点位置的中序后继者(叶子节点)中再次列出。另外,每一个叶子节点都会保存一个指向后一叶子节点的指针。所有记录都在叶节点,并且是顺序存放,各个叶节点(页为单位)都是逻辑的连续存放,是一个双向循环链表。
      如果是要随机查找,我们就从根节点出发,与B树的查找方式相同,只不过在分支节点即使找到了待查找的关键字,它也只是用来索引的,不能提供实际记录的访问,还是需要到达包含此关键字的终端节点。
      如果我们是需要从最小关键字进行从小到大的顺序查找,我们就可以从最左侧的叶子节点出发,不经过分支节点,而是沿着指向下一叶子节点的指针就可遍历所有的节点。
      B+树插入必须保证插入后叶节点中的记录依然排序,所以在插入时必须考虑以下三种情况:

    ![这里写图片描述](https://img-blog.csdnimg.cn/img_convert/8aa31d65665c0eb061d1de6ddf97e7d4.png)

      B+树索引在数据库中有一个特点就是其高扇出性,因此在数据库中,B+树高度一般在2-3层,也就是寻找某一键值的行记录,最多2-3次IO,而一般的磁盘每秒至少可以做100次IO,2-3次的意味着查询时间只需0.02-0.03秒。
    ##二、聚集索引、非聚集索引
      聚集索引与非聚集索引的区别是:页节点是否存放一整行记录
    ###2.1 聚集索引
      InnoDB存储引擎表是索引组织表,即表中数据按照主键顺序存放。而聚集索引就是按照每张表的主键构造一颗B+树,并且叶节点中存放着整张表的行记录数据,因此也让聚集索引的叶节点成为数据页。聚集索引的这个特性决定了索引组织表中的数据也是索引一部分。同B+树数据结构一样,每个数据页都通过一个双向链表来进行链接。
      实际数据也只能按照一颗B+树进行排序,因此每张表只能拥有一个聚集索引。在许多情况下,查询优化器非常倾向于采用聚集索引,因为聚集索引能够让我们在索引的叶节点直接找到数据。此外,由于定义了数据的逻辑顺序,聚集索引能够快速地访问针对范围值得到查询。查询优化器能够快速发现某一段范围的数据需要扫描。注意每一个页中的记录也是双向链表维护的。
    ###2.2 非聚集索引
      也称辅助索引,页级别不包含行的全部数据。页节点除了包含键值以外,每个页级别中的索引中还包含了一个书签,该书签用来告诉InnoDB存储引擎,哪里可以找到与索引相对应的行数据。因为InnoDB存储引擎表是索引组织表,因此InnoDB存储引擎的辅助索引书签就是相应行数据的聚集索引键。下图是聚集索引和辅助索引的关系:

    ![这里写图片描述](https://img-blog.csdnimg.cn/img_convert/2e5dae29868f6afcbff8b2dc2cecb27c.png)

      当通过辅助索引来寻找数据时,InnoDB存储引擎会遍历辅助索引并通过叶级别的指针获得指向主键索引的主键,然后再通过主键索引来找到了一个完整的行记录。举例来说:一颗高度为3的辅助索引树中查找数据,那么需要对这颗辅助索引遍历3次找到指定主键;如果聚集索引树的高度同样为3,那么还需要对聚集索引进行三次查找,才能查找一个完整的行数据所在的页,因此需要6次的逻辑Io来访问最终的一个数据页。

    ![这里写图片描述](https://img-blog.csdnimg.cn/img_convert/787b427ac2f470520f9c6bf1d00645d5.png) ![这里写图片描述](https://img-blog.csdnimg.cn/img_convert/f88ab678054e958b0a028e64a20b5f38.gif) ![这里写图片描述](https://img-blog.csdnimg.cn/img_convert/9af776c1425d204c33941796c7ce5c4d.gif)
    展开全文
  • 聚集索引,非聚集索引,覆盖索引 原理

    万次阅读 多人点赞 2018-08-28 11:37:34
    「数据库」和「数据库索引」这两个东西是在服务器端开发领域...然而, 会使用索引是一回事, 而深入理解索引原理又能恰到好处使用索引又是另一回事,这完全是两个天差地别的境界(我自己也还没有达到这层境界)。...

    数据库」和「数据库索引」这两个东西是在服务器端开发领域应用最为广泛的两个概念,熟练使用数据库和数据库索引是开发人员在行业内生存的必备技能

    使用索引很简单,只要能写创建表的语句,就肯定能写创建索引的语句,要知道这个世界上是不存在不会创建表的服务器端程序员的。然而, 会使用索引是一回事, 而深入理解索引原理又能恰到好处使用索引又是另一回事,这完全是两个天差地别的境界(我自己也还没有达到这层境界)。很大一部份程序员对索引的了解仅限于到“加索引能使查询变快”这个概念为止。

    • 为什么要给表加上主键?
    • 为什么加索引后会使查询变快?
    • 为什么加索引后会使写入、修改、删除变慢?
    • 什么情况下要同时在两个字段上建索引?

    这些问题他们可能不一定能说出答案。知道这些问题的答案有什么好处呢?如果开发的应用使用的数据库表中只有1万条数据,那么了解与不了解真的没有差别, 然而, 如果开发的应用有几百上千万甚至亿级别的数据,那么不深入了解索引的原理, 写出来程序就根本跑不动,就好比如果给货车装个轿车的引擎,这货车还能拉的动货吗?

    接下来就讲解一下上面提出的几个问题,希望对阅读者有帮助。

    网上很多讲解索引的文章对索引的描述是这样的「索引就像书的目录, 通过书的目录就准确的定位到了书籍具体的内容」,这句话描述的非常正确, 但就像脱了裤子放屁,说了跟没说一样,通过目录查找书的内容自然是要比一页一页的翻书找来的快,同样使用的索引的人难到会不知道,通过索引定位到数据比直接一条一条的查询来的快,不然他们为什么要建索引。

    想要理解索引原理必须清楚一种数据结构「平衡树」(非二叉),也就是b tree或者 b+ tree,重要的事情说三遍:“平衡树,平衡树,平衡树”。当然, 有的数据库也使用哈希桶作用索引的数据结构 , 然而, 主流的RDBMS都是把平衡树当做数据表默认的索引数据结构的。

    我们平时建表的时候都会为表加上主键, 在某些关系数据库中, 如果建表时不指定主键,数据库会拒绝建表的语句执行。 事实上, 一个加了主键的表,并不能被称之为「表」。一个没加主键的表,它的数据无序的放置在磁盘存储器上,一行一行的排列的很整齐, 跟我认知中的「表」很接近。如果给表上了主键,那么表在磁盘上的存储结构就由整齐排列的结构转变成了树状结构,也就是上面说的「平衡树」结构,换句话说,就是整个表就变成了一个索引。没错, 再说一遍, 整个表变成了一个索引,也就是所谓的「聚集索引」。

    这就是为什么一个表只能有一个主键, 一个表只能有一个「聚集索引」,因为主键的作用就是把「表」的数据格式转换成「索引(平衡树)」的格式放置。

    在这里插入图片描述

    上图就是带有主键的表(聚集索引)的结构图。图画的不是很好, 将就着看。其中树的所有结点(底部除外)的数据都是由主键字段中的数据构成,也就是通常我们指定主键的id字段。最下面部分是真正表中的数据。 假如我们执行一个SQL语句:

    select * from table where id = 1256;
    

    首先根据索引定位到1256这个值所在的叶结点,然后再通过叶结点取到id等于1256的数据行。 这里不讲解平衡树的运行细节, 但是从上图能看出,树一共有三层, 从根节点至叶节点只需要经过三次查找就能得到结果。如下图

    在这里插入图片描述

    假如一张表有一亿条数据 ,需要查找其中某一条数据,按照常规逻辑, 一条一条的去匹配的话, 最坏的情况下需要匹配一亿次才能得到结果,用大O标记法就是O(n)最坏时间复杂度,这是无法接受的,而且这一亿条数据显然不能一次性读入内存供程序使用, 因此, 这一亿次匹配在不经缓存优化的情况下就是一亿次IO开销,以现在磁盘的IO能力和CPU的运算能力, 有可能需要几个月才能得出结果 。

    如果把这张表转换成平衡树结构(一棵非常茂盛和节点非常多的树),假设这棵树有10层,那么只需要10次IO开销就能查找到所需要的数据, 速度以指数级别提升,用大O标记法就是O(log n),n是记录总树,底数是树的分叉数,结果就是树的层次数。换言之,查找次数是以树的分叉数为底,记录总数的对数,用公式来表示就是

    在这里插入图片描述

    用程序来表示就是Math.Log(100000000,10),100000000是记录数,10是树的分叉数(真实环境下分叉数远不止10), 结果就是查找次数,这里的结果从亿降到了个位数。因此,利用索引会使数据库查询有惊人的性能提升。

    然而, 事物都是有两面的, 索引能让数据库查询数据的速度上升, 而使写入数据的速度下降,原因很简单的, 因为平衡树这个结构必须一直维持在一个正确的状态, 增删改数据都会改变平衡树各节点中的索引数据内容,破坏树结构, 因此,在每次数据改变时, DBMS必须去重新梳理树(索引)的结构以确保它的正确,这会带来不小的性能开销,也就是为什么索引会给查询以外的操作带来副作用的原因。

    讲完聚集索引 , 接下来聊一下非聚集索引, 也就是我们平时经常提起和使用的常规索引。

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

    在这里插入图片描述

    每次给字段建一个新索引, 字段中的数据就会被复制一份出来, 用于生成索引。 因此, 给表添加索引,会增加表的体积, 占用磁盘存储空间。

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

    在这里插入图片描述

    不管以任何方式查询表, 最终都会利用主键通过聚集索引来定位到数据, 聚集索引(主键)是通往真实数据所在的唯一路径。

    然而, 有一种例外可以不使用聚集索引就能查询出所需要的数据, 这种非主流的方法 称之为「覆盖索引」查询, 也就是平时所说的复合索引或者多字段索引查询。 文章上面的内容已经指出, 当为字段建立索引以后, 字段中的内容会被同步到索引之中, 如果为一个索引指定两个字段, 那么这个两个字段的内容都会被同步至索引之中。

    先看下面这个SQL语句

    //建立索引
    
    create index index_birthday on user_info(birthday);
    
    //查询生日在1991年11月1日出生用户的用户名
    
    select user_name from user_info where birthday = '1991-11-1'
    
    

    这句SQL语句的执行过程如下:

    • 首先,通过非聚集索引index_birthday查找birthday等于1991-11-1的所有记录的主键ID值

    • 然后,通过得到的主键ID值执行聚集索引查找,找到主键ID值对就的真实数据(数据行)存储的位置

    • 最后, 从得到的真实数据中取得user_name字段的值返回, 也就是取得最终的结果

    我们把birthday字段上的索引改成双字段的覆盖索引

    create index index_birthday_and_user_name on user_info(birthday, user_name);
    

    这句SQL语句的执行过程就会变为:

    通过非聚集索引index_birthday_and_user_name查找birthday等于1991-11-1的叶节点的内容,然而, 叶节点中除了有user_name表主键ID的值以外, user_name字段的值也在里面, 因此不需要通过主键ID值的查找数据行的真实所在, 直接取得叶节点中user_name的值返回即可。 通过这种覆盖索引直接查找的方式, 可以省略不使用覆盖索引查找的后面两个步骤, 大大的提高了查询性能,如下图

    在这里插入图片描述

    数据库索引的大致工作原理就是像文中所述, 然而细节方面可能会略有偏差,这但并不会对概念阐述的结果产生影响 。

    展开全文
  • 说到索引,很多人都知道“索引是一个排序的列表,在这个列表中存储着索引的值和包含这个值的数据所在行的物理地址,在数据十分庞大的时候,索引可以大大加快查询的速度,这是因为使用索引后可以不用扫描全表来定位某...

    说到索引,很多人都知道“索引是一个排序的列表,在这个列表中存储着索引的值和包含这个值的数据所在行的物理地址,在数据十分庞大的时候,索引可以大大加快查询的速度,这是因为使用索引后可以不用扫描全表来定位某行的数据,而是先通过索引表找到该行数据对应的物理地址然后访问相应的数据。

    但是索引是怎么实现的呢?因为索引并不是关系模型的组成部分,因此不同的DBMS有不同的实现,我们针对MySQL数据库的实现进行说明。本文内容涉及MySQL中索引的语法索引的优缺点、索引的分类、索引的实现原理、索引的使用策略、索引的优化几部分。

    目录

    一、MySQL中索引的语法

    二、索引的优缺点

    三、索引的分类

    四、索引的实现原理

    1、哈希索引:

    2、全文索引:

    3、BTree索引和B+Tree索引

    *    聚簇索引和非聚簇索引

    五、索引的使用策略

    六、索引的优化


    一、MySQL中索引的语法

    创建索引

    在创建表的时候添加索引

    CREATE TABLE mytable(  
        ID INT NOT NULL,   
        username VARCHAR(16) NOT NULL,  
        INDEX [indexName] (username(length))  
    ); 

    在创建表以后添加索引

    ALTER TABLE my_table ADD [UNIQUE] INDEX index_name(column_name);
    或者
    CREATE INDEX index_name ON my_table(column_name);

    注意:

    1、索引需要占用磁盘空间,因此在创建索引时要考虑到磁盘空间是否足够

    2、创建索引时需要对表加锁,因此实际操作中需要在业务空闲期间进行

    根据索引查询

    具体查询:
    SELECT * FROM table_name WHERE column_1=column_2;(为column_1建立了索引)
    
    或者模糊查询
    SELECT * FROM table_name WHERE column_1 LIKE '%三'
    SELECT * FROM table_name WHERE column_1 LIKE '三%'
    SELECT * FROM table_name WHERE column_1 LIKE '%三%'
    
    SELECT * FROM table_name WHERE column_1 LIKE '_好_'
    
    如果要表示在字符串中既有A又有B,那么查询语句为:
    SELECT * FROM table_name WHERE column_1 LIKE '%A%' AND column_1 LIKE '%B%';
    
    SELECT * FROM table_name WHERE column_1 LIKE '[张李王]三';  //表示column_1中有匹配张三、李三、王三的都可以
    SELECT * FROM table_name WHERE column_1 LIKE '[^张李王]三';  //表示column_1中有匹配除了张三、李三、王三的其他三都可以
    
    //在模糊查询中,%表示任意0个或多个字符;_表示任意单个字符(有且仅有),通常用来限制字符串长度;[]表示其中的某一个字符;[^]表示除了其中的字符的所有字符
    
    或者在全文索引中模糊查询
    SELECT * FROM table_name WHERE MATCH(content) AGAINST('word1','word2',...);

    删除索引

    DROP INDEX my_index ON tablename;
    或者
    ALTER TABLE table_name DROP INDEX index_name;
    

    查看表中的索引

    SHOW INDEX FROM tablename

    查看查询语句使用索引的情况

    //explain 加查询语句
    explain SELECT * FROM table_name WHERE column_1='123';
    

    二、索引的优缺点

    优势:可以快速检索,减少I/O次数,加快检索速度;根据索引分组和排序,可以加快分组和排序;

    劣势:索引本身也是表,因此会占用存储空间,一般来说,索引表占用的空间的数据表的1.5倍;索引表的维护和创建需要时间成本,这个成本随着数据量增大而增大;构建索引会降低数据表的修改操作(删除,添加,修改)的效率,因为在修改数据表的同时还需要修改索引表;

    三、索引的分类

    常见的索引类型有:主键索引、唯一索引、普通索引、全文索引、组合索引

    1、主键索引:即主索引,根据主键pk_clolum(length)建立索引,不允许重复,不允许空值

    ALTER TABLE 'table_name' ADD PRIMARY KEY pk_index('col');

    2、唯一索引:用来建立索引的列的值必须是唯一的,允许空值

    ALTER TABLE 'table_name' ADD UNIQUE index_name('col');

    3、普通索引:用表中的普通列构建的索引,没有任何限制

    ALTER TABLE 'table_name' ADD INDEX index_name('col');

    4、全文索引:用大文本对象的列构建的索引(下一部分会讲解)

    ALTER TABLE 'table_name' ADD FULLTEXT INDEX ft_index('col');

    5、组合索引:用多个列组合构建的索引,这多个列中的值不允许有空值

    ALTER TABLE 'table_name' ADD INDEX index_name('col1','col2','col3');

    *遵循“最左前缀”原则,把最常用作为检索或排序的列放在最左,依次递减,组合索引相当于建立了col1,col1col2,col1col2col3三个索引,而col2或者col3是不能使用索引的。

    *在使用组合索引的时候可能因为列名长度过长而导致索引的key太大,导致效率降低,在允许的情况下,可以只取col1和col2的前几个字符作为索引

    ALTER TABLE 'table_name' ADD INDEX index_name(col1(4),col2(3));

    表示使用col1的前4个字符和col2的前3个字符作为索引

    四、索引的实现原理

    MySQL支持诸多存储引擎,而各种存储引擎对索引的支持也各不相同,因此MySQL数据库支持多种索引类型,如BTree索引,B+Tree索引,哈希索引,全文索引等等

    1、哈希索引:

    只有memory(内存)存储引擎支持哈希索引,哈希索引用索引列的值计算该值的hashCode,然后在hashCode相应的位置存执该值所在行数据的物理位置,因为使用散列算法,因此访问速度非常快,但是一个值只能对应一个hashCode,而且是散列的分布方式,因此哈希索引不支持范围查找和排序的功能。

    2、全文索引:

    FULLTEXT(全文)索引,仅可用于MyISAM和InnoDB,针对较大的数据,生成全文索引非常的消耗时间和空间。对于文本的大对象,或者较大的CHAR类型的数据,如果使用普通索引,那么匹配文本前几个字符还是可行的,但是想要匹配文本中间的几个单词,那么就要使用LIKE %word%来匹配,这样需要很长的时间来处理,响应时间会大大增加,这种情况,就可使用时FULLTEXT索引了,在生成FULLTEXT索引时,会为文本生成一份单词的清单,在索引时及根据这个单词的清单来索引。FULLTEXT可以在创建表的时候创建,也可以在需要的时候用ALTER或者CREATE INDEX来添加:

    //创建表的时候添加FULLTEXT索引
    CTREATE TABLE my_table(
        id INT(10) PRIMARY KEY,
        name VARCHAR(10) NOT NULL,
        my_text TEXT,
        FULLTEXT(my_text)
    )ENGINE=MyISAM DEFAULT CHARSET=utf8;
    //创建表以后,在需要的时候添加FULLTEXT索引
    ALTER TABLE my_table ADD FULLTEXT INDEX ft_index(column_name);

    全文索引的查询也有自己特殊的语法,而不能使用LIKE %查询字符串%的模糊查询语法

    SELECT * FROM table_name MATCH(ft_index) AGAINST('查询字符串');

    注意:

    *对于较大的数据集,把数据添加到一个没有FULLTEXT索引的表,然后添加FULLTEXT索引的速度比把数据添加到一个已经有FULLTEXT索引的表快。

    *5.6版本前的MySQL自带的全文索引只能用于MyISAM存储引擎,如果是其它数据引擎,那么全文索引不会生效。5.6版本之后InnoDB存储引擎开始支持全文索引

    *在MySQL中,全文索引支队英文有用,目前对中文还不支持。5.7版本之后通过使用ngram插件开始支持中文。

    *在MySQL中,如果检索的字符串太短则无法检索得到预期的结果,检索的字符串长度至少为4字节,此外,如果检索的字符包括停止词,那么停止词会被忽略。

    * 更深入的理解参考文章:全文索引的深入理解

     

    3、BTree索引和B+Tree索引

     

    • BTree索引

    BTree是平衡搜索多叉树,设树的度为2d(d>1),高度为h,那么BTree要满足以一下条件:

    • 每个叶子结点的高度一样,等于h;
    • 每个非叶子结点由n-1个keyn个指针point组成,其中d<=n<=2d,key和point相互间隔,结点两端一定是key;
    • 叶子结点指针都为null;
    • 非叶子结点的key都是[key,data]二元组,其中key表示作为索引的键,data为键值所在行的数据;

    BTree的结构如下:

    在BTree的机构下,就可以使用二分查找的查找方式,查找复杂度为h*log(n),一般来说树的高度是很小的,一般为3左右,因此BTree是一个非常高效的查找结构。

    BTree的查询、插入、删除过程可以参考:https://blog.csdn.net/endlu/article/details/51720299

    • B+Tree索引

    B+Tree是BTree的一个变种,设d为树的度数,h为树的高度,B+Tree和BTree的不同主要在于:

    • B+Tree中的非叶子结点不存储数据,只存储键值;
    • B+Tree的叶子结点没有指针,所有键值都会出现在叶子结点上,且key存储的键值对应data数据的物理地址;
    • B+Tree的每个非叶子节点由n个键值keyn个指针point组成;

    B+Tree的结构如下:

    B+Tree对比BTree的优点:

    1、磁盘读写代价更低

    一般来说B+Tree比BTree更适合实现外存的索引结构,因为存储引擎的设计专家巧妙的利用了外存(磁盘)的存储结构,即磁盘的最小存储单位是扇区(sector),而操作系统的块(block)通常是整数倍的sector,操作系统以页(page)为单位管理内存,一页(page)通常默认为4K,数据库的页通常设置为操作系统页的整数倍,因此索引结构的节点被设计为一个页的大小,然后利用外存的“预读取”原则,每次读取的时候,把整个节点的数据读取到内存中,然后在内存中查找,已知内存的读取速度是外存读取I/O速度的几百倍,那么提升查找速度的关键就在于尽可能少的磁盘I/O,那么可以知道,每个节点中的key个数越多,那么树的高度越小,需要I/O的次数越少,因此一般来说B+Tree比BTree更快,因为B+Tree的非叶节点中不存储data,就可以存储更多的key

    2、查询速度更稳定

    由于B+Tree非叶子节点不存储数据(data),因此所有的数据都要查询至叶子节点,而叶子节点的高度都是相同的,因此所有数据的查询速度都是一样的。

    更多操作系统内容参考:

    硬盘结构

    扇区、块、簇、页的区别

    操作系统层优化(进阶,初学不用看)

    • 带顺序索引的B+TREE

    很多存储引擎在B+Tree的基础上进行了优化,添加了指向相邻叶节点的指针,形成了带有顺序访问指针的B+Tree,这样做是为了提高区间查找的效率,只要找到第一个值那么就可以顺序的查找后面的值。

    B+Tree的结构如下:

     

    聚簇索引和非聚簇索引

    分析了MySQL的索引结构的实现原理,然后我们来看看具体的存储引擎怎么实现索引结构的,MySQL中最常见的两种存储引擎分别是MyISAM和InnoDB,分别实现了非聚簇索引和聚簇索引。

    聚簇索引的解释是:聚簇索引的顺序就是数据的物理存储顺序

    非聚簇索引的解释是:索引顺序与数据物理排列顺序无关

    这样说起来并不好理解,让人摸不着头脑,清继续看下文,并在插图下方对上述两句话有解释

    首先要介绍几个概念,在索引的分类中,我们可以按照索引的键是否为主键来分为“主索引”和“辅助索引”,使用主键键值建立的索引称为“主索引”,其它的称为“辅助索引”。因此主索引只能有一个,辅助索引可以有很多个。

    MyISAM——聚簇索引

    • MyISAM存储引擎采用的是非聚簇索引,非聚簇索引的主索引和辅助索引几乎是一样的,只是主索引不允许重复,不允许空值,他们的叶子结点的key都存储指向键值对应的数据的物理地址
    • 非聚簇索引的数据表和索引表是分开存储的。
    • 非聚簇索引中的数据是根据数据的插入顺序保存。因此非聚簇索引更适合单个数据的查询。插入顺序不受键值影响。
    • 只有在MyISAM中才能使用FULLTEXT索引。(mysql5.6以后innoDB也支持全文索引)

    *最开始我一直不懂既然非聚簇索引的主索引和辅助索引指向相同的内容,为什么还要辅助索引这个东西呢,后来才明白索引不就是用来查询的吗,用在那些地方呢,不就是WHERE和ORDER BY 语句后面吗,那么如果查询的条件不是主键怎么办呢,这个时候就需要辅助索引了。

    InnoDB——聚簇索引

    • 聚簇索引的主索引的叶子结点存储的是键值对应的数据本身,辅助索引的叶子结点存储的是键值对应的数据的主键键值。因此主键的值长度越小越好,类型越简单越好。
    • 聚簇索引的数据和主键索引存储在一起
    • 聚簇索引的数据是根据主键的顺序保存。因此适合按主键索引的区间查找,可以有更少的磁盘I/O,加快查询速度。但是也是因为这个原因,聚簇索引的插入顺序最好按照主键单调的顺序插入,否则会频繁的引起页分裂,严重影响性能。
    • 在InnoDB中,如果只需要查找索引的列,就尽量不要加入其它的列,这样会提高查询效率。

     

    *使用主索引的时候,更适合使用聚簇索引,因为聚簇索引只需要查找一次,而非聚簇索引在查到数据的地址后,还要进行一次I/O查找数据。

    *因为聚簇辅助索引存储的是主键的键值,因此可以在数据行移动或者页分裂的时候降低成本,因为这时不用维护辅助索引。但是由于主索引存储的是数据本身,因此聚簇索引会占用更多的空间。

    *聚簇索引在插入新数据的时候比非聚簇索引慢很多,因为插入新数据时需要检测主键是否重复,这需要遍历主索引的所有叶节点,而非聚簇索引的叶节点保存的是数据地址,占用空间少,因此分布集中,查询的时候I/O更少,但聚簇索引的主索引中存储的是数据本身,数据占用空间大,分布范围更大,可能占用好多的扇区,因此需要更多次I/O才能遍历完毕。

    下图可以形象的说明聚簇索引和非聚簇索引的区别

    从上图中可以看到聚簇索引的辅助索引的叶子节点的data存储的是主键的值,主索引的叶子节点的data存储的是数据本身,也就是说数据和索引存储在一起,并且索引查询到的地方就是数据(data)本身,那么索引的顺序和数据本身的顺序就是相同的;

    而非聚簇索引的主索引和辅助索引的叶子节点的data都是存储的数据的物理地址,也就是说索引和数据并不是存储在一起的,数据的顺序和索引的顺序并没有任何关系,也就是索引顺序与数据物理排列顺序无关。

     

    此外MyISAM和innoDB的区别总结如下:

    MyISAM和innoDB引擎对比
      MyISAM innoDB
    索引类型 非聚簇 聚簇
    支持事务
    支持表锁
    支持行锁 是(默认)
    支持外键
    支持全文索引 是(5.6以后支持)
    适用操作类型 大量select下使用 大量insert、delete和update下使用

    总结如下:

    • InnoDB 支持事务,支持行级别锁定,支持 B-tree、Full-text 等索引,不支持 Hash 索引;
    • MyISAM 不支持事务,支持表级别锁定,支持 B-tree、Full-text 等索引,不支持 Hash 索引;

    此外,Memory 不支持事务,支持表级别锁定,支持 B-tree、Hash 等索引,不支持 Full-text 索引;

    更多MyISAM和innoDB的区别具体内容参考:MyISAMheinnoDB的区别,包括行级锁死锁的具体分析

     

    五、索引的使用策略

     

    什么时候要使用索引?

    • 主键自动建立唯一索引;
    • 经常作为查询条件在WHERE或者ORDER BY 语句中出现的列要建立索引;
    • 作为排序的列要建立索引;
    • 查询中与其他表关联的字段,外键关系建立索引
    • 高并发条件下倾向组合索引;
    • 用于聚合函数的列可以建立索引,例如使用了max(column_1)或者count(column_1)时的column_1就需要建立索引

    什么时候不要使用索引?

    • 经常增删改的列不要建立索引;
    • 有大量重复的列不建立索引;
    • 表记录太少不要建立索引。只有当数据库里已经有了足够多的测试数据时,它的性能测试结果才有实际参考价值。如果在测试数据库里只有几百条数据记录,它们往往在执行完第一条查询命令之后就被全部加载到内存里,这将使后续的查询命令都执行得非常快--不管有没有使用索引。只有当数据库里的记录超过了1000条、数据总量也超过了MySQL服务器上的内存总量时,数据库的性能测试结果才有意义。

    索引失效的情况:

    • 在组合索引中不能有列的值为NULL,如果有,那么这一列对组合索引就是无效的。
    • 在一个SELECT语句中,索引只能使用一次,如果在WHERE中使用了,那么在ORDER BY中就不要用了。
    • LIKE操作中,'%aaa%'不会使用索引,也就是索引会失效,但是‘aaa%’可以使用索引。
    • 在索引的列上使用表达式或者函数会使索引失效,例如:select * from users where YEAR(adddate)<2007,将在每个行上进行运算,这将导致索引失效而进行全表扫描,因此我们可以改成:select * from users where adddate<’2007-01-01′。其它通配符同样,也就是说,在查询条件中使用正则表达式时,只有在搜索模板的第一个字符不是通配符的情况下才能使用索引。
    • 在查询条件中使用不等于,包括<符号、>符号和!=会导致索引失效。特别的是如果对主键索引使用!=则不会使索引失效,如果对主键索引或者整数类型的索引使用<符号或者>符号不会使索引失效。(经erwkjrfhjwkdb同学提醒,不等于,包括&lt;符号、>符号和!,如果占总记录的比例很小的话,也不会失效)
    • 在查询条件中使用IS NULL或者IS NOT NULL会导致索引失效。
    • 字符串不加单引号会导致索引失效。更准确的说是类型不一致会导致失效,比如字段email是字符串类型的,使用WHERE email=99999 则会导致失败,应该改为WHERE email='99999'。
    • 在查询条件中使用OR连接多个条件会导致索引失效,除非OR链接的每个条件都加上索引,这时应该改为两次查询,然后用UNION ALL连接起来。
    • 如果排序的字段使用了索引,那么select的字段也要是索引字段,否则索引失效。特别的是如果排序的是主键索引则select * 也不会导致索引失效。
    • 尽量不要包括多列排序,如果一定要,最好为这队列构建组合索引;

     

    六、索引的优化

     

    1、最左前缀

    索引的最左前缀和和B+Tree中的“最左前缀原理”有关,举例来说就是如果设置了组合索引<col1,col2,col3>那么以下3中情况可以使用索引:col1,<col1,col2>,<col1,col2,col3>,其它的列,比如<col2,col3>,<col1,col3>,col2,col3等等都是不能使用索引的。

    根据最左前缀原则,我们一般把排序分组频率最高的列放在最左边,以此类推

    2、带索引的模糊查询优化

    在上面已经提到,使用LIKE进行模糊查询的时候,'%aaa%'不会使用索引,也就是索引会失效。如果是这种情况,只能使用全文索引来进行优化(上文有讲到)。

    3、为检索的条件构建全文索引,然后使用

    SELECT * FROM tablename MATCH(index_colum) ANGAINST(‘word’);

    4、使用短索引

    对串列进行索引,如果可能应该指定一个前缀长度。例如,如果有一个CHAR(255)的 列,如果在前10 个或20 个字符内,多数值是惟一的,那么就不要对整个列进行索引。短索引不仅可以提高查询速度而且可以节省磁盘空间和I/O操作。

     

    展开全文
  • Oracle索引原理

    千次阅读 2017-10-23 17:17:18
    索引原理 oracle中的索引与mysql中的索引不一样,oracle中索引是存储了索引列的值以及rowid值。而mysql索引分为聚集索引,非聚集索引。其中聚集索引只能有一个。 oracle中索引的主要分为根,茎,叶子三部分。索引列...
  • 数据库的索引原理 索引作用 索引是用来快速查找特定值的记录。如果没有索引、一般来说执行查询时会遍历整个表。索引就是把无须的数据变成有序的,然后提高查询效率。 索引案例 索引原理 1、把创建了索引的列进行排序...
  • oracle索引原理

    千次阅读 2017-07-11 09:47:16
    一、索引原理   Oracle提供了大量索引选项。知道在给定条件下使用哪个选项对于一个应用程序的性能来说非常重要。一个错误的选择可能会引发死锁,并导致数据库性能急剧下降或进程终止。而如果做出正确的选择,则...
  • Lucene简介和索引原理

    千次阅读 2017-12-14 09:55:28
    基于Lucene检索引擎我们开发了自己的全文检索系统,承担起后台PB级、万亿条数据记录的检索工作,这里向... Lucene简介和索引原理 该部分从三方面展开:Lucene简介、索引原理、Lucene索引实现。1.1 Lucene简介 Lucen
  • 基于Lucene检索引擎我们开发了自己的全文检索系统,承担起后台PB级、万亿条数据记录的检索工作,这里向... Lucene简介和索引原理 该部分从三方面展开:Lucene简介、索引原理、Lucene索引实现。1.1 Lucene简介 Lucen
  • **深入理解MySQL索引原理** 熊大 说索引之前我们先谈下mysql 这个渣男。 它支持诸多存储引擎,各存储引擎对索引的支持也各不相同,因此MySQL支持多种索引类型,如BTree索引,B+Tree索引,哈希索引,有序数组、...
  • Mysql索引原理之字符串前缀索引

    千次阅读 2019-06-20 16:30:13
    Mysql索引原理之字符串前缀索引 前面已经提到,对于非主键的字符串类型索引,也会按照字段的值建立 一套B+Tree的结构,默认是以值的字典序来排的。然后叶子节点挂着的 是主键的id,因为它们是同一条记录,然后去主键...
  • MySQL索引原理及BTree(B-/+Tree)结构详解

    万次阅读 多人点赞 2018-11-20 16:52:25
    索引的本质 B-Tree和B+Tree B-Tree B+Tree 带有顺序访问指针的B+Tree 为什么使用B-Tree(B+Tree) 主存存取原理 磁盘存取原理 局部性原理与磁盘预读 B-/+Tree索引的性能分析 MySQL索引实现 MyISAM索引...
  • MySQL索引原理

    万次阅读 多人点赞 2016-02-02 20:53:39
    B+树索引是B+树在数据库中的一种实现,是最常见也是数据库中使用最为频繁的一种索引。B+树中的B代表平衡(balance),而不是二叉(binary),因为B+树是从最早的平衡二叉树演化而来的。在讲B+树之前必须先了解二叉...
  • 深入浅出数据库索引原理

    万次阅读 2018-08-20 15:40:49
    使用索引很简单,只要能写创建表的语句,就肯定能写创建索引的语句,要知道这个世界上是不存在不会创建表的服务器端程序员的。然而, 会使用索引是一回事, 而深入理解索引原理又能恰到好处...
  • MySQL索引原理、失效情况

    万次阅读 多人点赞 2019-04-19 17:19:17
    声明:本文是小编在学习过程中,...1.2 主键索引和普通索引的区别 1.3 唯一索引vs普通索引 2 mysql索引优化 2.1 查看索引使用情况 2.2 mysql索引使用策略 2.3 mysql索引使用原则 1 mysql索引知识 1.1 ...
  • Lucene底层原理和优化经验分享:Lucene简介和索引原理
  • Oracle加数据库索引原理

    千次阅读 2019-03-06 16:48:19
    然而, 会使用索引是一回事, 而深入理解索引原理又能恰到好处使用索引又是另一回事,这完全是两个天差地别的境界(我自己也还没有达到这层境界)。很大一部份程序员对索引的了解仅限于到“加索引能使查询变快”这个...
  • 倒排索引原理和实现

    万次阅读 多人点赞 2017-03-06 22:17:47
    倒排索引原理和实现 关于倒排索引 搜索引擎通常检索的场景是:给定几个关键词,找出包含关键词的文档。怎么快速找到包含某个关键词的文档就成为搜索的关键。这里我们借助单词——文档矩阵模型,通过这个模型...
  • 数据库索引原理与优化 文章目录数据库索引原理与优化一. 数据库索引简介二. 红黑树 与 B-Tree1. 红黑树2. B-Tree三. MySQL 的完美解决方案 —— B+Tree 一. 数据库索引简介 索引是帮助 MySQL 高效获取数据的,已排...
  • 【数据库】数据库索引原理

    千次阅读 2019-06-04 08:45:40
    3.索引原理B+ tree4.B+ tree 在两大引擎中的体现5.索引的原则 1.索引是什么? 索引是为了加速对表中数据行的检索而创建的一种分散存储的数据结构。 2.为什么? 索引能极大的减少存储引擎需要扫描的数据量 索引可以...
  • Mysql索引原理

    千次阅读 2018-06-05 21:22:11
    Mysql索引类型及其特性普通索引 最基本的索引,它没有任何限制,也是我们大多数情况下用到的索引。–直接创建索引 CREATE INDEX index_name ON table(column(length)) –修改表结构的方式添加索引 ALTER TABLE ...
  • MySQL索引原理及B-Tree / B+Tree结构详解

    万次阅读 2019-08-09 12:30:22
    MySQL索引原理及B-Tree / B+Tree结构详解 目录 摘要 数据结构及算法基础 索引的本质 B-Tree和B+Tree B-Tree B+Tree 带有顺序访问指针的B+Tree 为什么使用B-Tree(B+Tree) 主存存取原理 磁盘存取原理 ...
  • 索引原理-索引数据结构

    千次阅读 2021-01-25 22:18:20
    巨簇索引 非巨簇索引 联合索引 一. 二叉树 插入顺序: 4 2 1 10 6 7 首先, 左侧叶子节点 < 主节点 < 右侧叶子节点 我们乱序插入一些数据, 我们会发现0010这个节点被“孤立”了, 随着数据量的增加树的H(高度)...
  • Elasticsearch系列1—索引原理

    千次阅读 2020-06-02 11:17:07
    Elasticsearch—索引原理 一、介绍 Elasticsearch 是一个分布式可扩展的实时搜索引擎和分析引擎,一个建立在全文搜索引擎A**pache Lucene™**基础上的搜索引擎。当然Elasticsearch并不仅仅是Lucene,它不仅包括了...
  • 索引原理学习

    千次阅读 多人点赞 2018-08-14 22:47:47
    1.什么是索引? 一般的应用系统,读写比例在10:1左右,而且插入操作和一般的更新操作很少出现性能问题,在生产环境中,我们遇到最多的,也是最容易出问题的,还是一些复杂的查询操作,因此对查询语句的优化显然是重...
  • oracle-索引原理

    千次阅读 2014-12-17 17:38:55
    Oracle索引原理 Oracle提供了大量索引选项。知道在给定条件下使用哪个选项对于一个应用程序的性能来说非常重要。一个错误的选择可能会引发死锁,并导致数据库性能急剧下降或进程终止。而如果做出正确的选择,则可以...
  • MongoDB索引原理

    千次阅读 2019-07-09 15:04:54
    为什么需要索引? 当你抱怨MongoDB集合查询效率低的时候,可能你就需要考虑使用索引了,为了方便后续介绍,先科普下MongoDB里的索引机制(同样适用于其他的数据库比如mysql)。 mongo-9552:PRIMARY&gt; db....

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 365,001
精华内容 146,000
关键字:

索引的原理