MySQL索引分析（一）
这是学习笔记的第 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树的存储方式：
如下是B+树的存储方式：
我们来做下对比和分析，
1）B树和B+树很大的不同是，B树的键值不会出现多次，而对于B+树却不同，键值对应的具体数据都在叶子节点上。这个可以通过生活中的例子来联系，比如一个公司里面，有一个开发小组，组长管理着一些程序员，他平时也会参与一些关键任务的开发工作，虽然从组织架构上它属于管理层，但是也是做一些具体事务的。
2）B树查询效率与在B树的存储位置有关，而相对来说B+树是相对稳定的。同样可以用一个例子来解释，现在很多公司提倡扁平化管理，彼此之间都是平行的，开展工作也会方便一些，B+树的方式也是类似。
3）B+树的叶子节点是跟后续节点连接的，形成了一个链表，我们查询数据的时候，不一定只查出一条，如果是多条，对于B树来说，就需要做局部的中序遍历，可能会跨层访问，而对于B+树来说，数据都在叶子节点，而且是有序的，处理起来会容易的多。同样可以举一个例子，有些公司为了提高工作效率，弱化“部门墙”问题，会有一些产品研发的虚拟小组，组员可能是来自于多个部门抽调。
当然从存储的角度来考虑，因为B+树的键不光在叶子节点，还可能在非叶子节点中重复出现，所以从存储空间上，B+树相比B树会有额外的空间开销，相比于性能来说，这种消耗也是可以平衡的。