这是学习笔记的第 1983 篇文章

 对于MySQL索引,准备分成几个部分来进行说明,我们先来第一篇。

首先来说下什么是索引组织表?

在学习MySQL开发规范-索引规范的时候,强调过一个要点:每张表都建议有主键。我们在这里来简单分析一下为什么?

从存储方式上来说,在InnoDB存储引擎中,表都是按照主键的顺序进行存放的,我们叫做索引组织表(IOT),表中主键的参考依据如下:

1.显式的创建主键Praimary key

2.判断表中是否有非空唯一索引,如果有,则为主键

3.如果都不符合上述条件,则会生成UUID的一个隐式主键(6字节大)

 

我们举一个例子来说明一下,我们创建一张表test_index,含有主键,唯一性索引和非唯一性索引。

CREATE TABLE `test_index` (

  `a` int(11) NOT NULL,

  `b` int(11) DEFAULT NULL,

  `c` int(11) DEFAULT NULL,

  `d` int(11) DEFAULT NULL,

  PRIMARY KEY (`a`),

  UNIQUE KEY `b` (`b`),

  KEY `c` (`c`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8;

插入3条数据,其中字段c和d的数据不唯一

insert into test_index select 1,2,3,4;

insert into test_index select 2,3,3,4;

insert into test_index select 3,4,5,4;

我们使用rowid的方式来查看。

mysql> select _rowid,a,b,c,d from test_index;

+--------+---+------+------+------+

| _rowid | a | b    | c    | d    |

+--------+---+------+------+------+

|      1 | 1 |    2 |    3 |    4 |

|      2 | 2 |    3 |    3 |    4 |

|      3 | 3 |    4 |    5 |    4 |

+--------+---+------+------+------+

如果删除主键,我们看看rowid的情况。

在MySQL里,对于主键的依赖远比其他数据库要高,我们常听到的索引,比如唯一性索引,非唯一性索引,覆盖索引等都是辅助索引(secondary index,也叫二级索引),从存储的角度来说,InnoDB的二级索引列中默认包含主键列,如果主键太长,也会使得二级索引很占空间。

 

接下来说下B+树是什么

对于数据库的设计来说,如何高效的查询数据是重中之重,所以我们需要熟悉索引的存储结构。

对于数据库和文件系统中,大量使用了平衡二叉树来实现索引,对于MySQL来说,是使用B+树的方式,我们来对两种存储方式做下分析。

如下是B树的存储方式:

MySQL索引分析(一)_MySQL索引分析

 

如下是B+树的存储方式:

MySQL索引分析(一)_MySQL索引分析_02

 

我们来做下对比和分析,

1)B树和B+树很大的不同是,B树的键值不会出现多次,而对于B+树却不同,键值对应的具体数据都在叶子节点上。这个可以通过生活中的例子来联系,比如一个公司里面,有一个开发小组,组长管理着一些程序员,他平时也会参与一些关键任务的开发工作,虽然从组织架构上它属于管理层,但是也是做一些具体事务的。

2)B树查询效率与在B树的存储位置有关,而相对来说B+树是相对稳定的。同样可以用一个例子来解释,现在很多公司提倡扁平化管理,彼此之间都是平行的,开展工作也会方便一些,B+树的方式也是类似。

3)B+树的叶子节点是跟后续节点连接的,形成了一个链表,我们查询数据的时候,不一定只查出一条,如果是多条,对于B树来说,就需要做局部的中序遍历,可能会跨层访问,而对于B+树来说,数据都在叶子节点,而且是有序的,处理起来会容易的多。同样可以举一个例子,有些公司为了提高工作效率,弱化“部门墙”问题,会有一些产品研发的虚拟小组,组员可能是来自于多个部门抽调。

当然从存储的角度来考虑,因为B+树的键不光在叶子节点,还可能在非叶子节点中重复出现,所以从存储空间上,B+树相比B树会有额外的空间开销,相比于性能来说,这种消耗也是可以平衡的。

 

 

MySQL索引分析(一)_MySQL索引分析_03