mysql索引小结以及B树和B+树数据结构小结

一.前序:

        索引(index)是存在于存储引擎层面的，不是所有的存储引擎都支持所有的索引类型，即使多种存储引擎支持同一种索引类型，它们的实现和行为可能也有区别.

 

二.索引类型:(数据结构的角度)

        a.B-tree索引:

            常见的索引类型，是基于B-tree数据结构。B-tree的基本思想是，可以参与排序，所有值(被索引的列)都是排过序的，每个叶节点到根节点的距离都相同。所以B-tree适合用来查找某一范围内的数据，而且可以支持数据排序。但当索引多列时，列的顺序特别重要，需要注意。Innodb和MyISAM都支持B-tree，其中Innodb默认的是B-tree，MyISAM为了节省空间，对索引进行了压缩，因此牺牲了性能。

        b.hash索引:

            是基于hash表，因此只支持精确查找，不支持范围查找或者排序。因此，对于范围查找或者排序都需要服务层来处理，添加了工作任务量。目前的Memory存储引擎是默认支持hash索引的，但是它支持的hash索引是nonunique的，冲突太多会影响查询性能，此外，Memory存储引擎也是支持B-tree索引的。

        例如:  

CREATE TABLE test (
    username VARCHAR(50) NOT NULL,
    password VARCHAR(50) NOT NULL,
    KEY USING HASH(username)
) ENGINE =MEMORY;

    

                b1.仅仅能满足“=”，<,>,in的查询，不能满足范围查询

                b2.查询效率很高，不用和B-tree一样，从根节点到枝节点，因此查询效率是高于B-tree的。

                b3.只有Memory存储引擎显示支持hash索引

        c.Full-text索引:

            主要用来查找文本中的关键字，通过关键字去查询，而不是直接和索引中的值相比较，Full-text更像是一个搜索引擎，不是简单的where的查询语句，你可以对一列进行Full-text索引和B-tree索引，两者不冲突，Full-text配合match against使用，不是简单的where的like查询。

        d.R-tree索引(空间索引):

            只有MyISAM支持的索引，而且支持的也不是很好，忽视。 

 

 

三. B树和B+树小结:

            B树是二叉搜索树的一种延伸，其中是通过根节点来进行搜索，小于根节点关键字，则进入左子节点，大于则进入右子节点，但B树可以有多个子节点，不仅仅是两个子节点。

 

            B+树是在B树的基础上添加了叶子节点链表指针，同时将非叶子节点作为叶子节点的索引，B+树是在叶子节点才会命中。

 

            两者区别:

                1.数据存储位置不同:B树是数据存储在每一个节点中，B+树是数据存储在叶子节点中，同时B+树是非叶子节点上是作为查询索引，来提升查询效率。

                2.分支节点构造:B+树的分支节点存储的是关键字信息和儿子的指针(这里的指针指的是一个指向)，也就是非叶子节点不仅仅是存储着索引信息。这就决定了B+树更适合存储外部数据，也就是磁盘数据。

                3.查询方式不同:B树找到具体的关键字，结束。B+树则需要通过索引找到叶子节点数据才结束。因此，对于B+树，IO读取次数少，这是优点之一，同时对于所有的叶子节点，包含所有的关键字，并以有序的链表结构存储，可提高删除效率，因为B+树是从根节点到叶子节点，所以查询效率很稳定。

 

 

                    针对Mongdb和mysql使用的数据结构，mongdb使用的是B树，因为是nosql，对于性能需求要求挺高，同时数据是存储在内存中的，而不是存储在磁盘数据中，每个节点都存储数据，都是个Data域，因此，使用的是B树结构。mysql使用的是B+树结构

                    索引也是有大小的，一般索引建的多，索引文件也挺大的，所以这就涉及大磁盘IO的读取，因为B+树结构中不是每个节点都储存信息，只是在叶子节点存储信息，所以这种数据结构适合磁盘信息存储(减少IO读取消耗)

 

转载于:https://my.oschina.net/u/3110937/blog/1796673