B-Tree 索引

8.4  合理设计并利用索引

索引优化，可以说是数据库相关优化，尤其是Query 优化中最常用的优化手段之一。很多人大部分时候都只是大概了解索引的用途，知道索引能够让 Query 执行得更快，但并不知道为什么会更快。尤其是索引的实现原理、存储方式，以及不同索引之间的区别等就更不清楚了。正因为索引对Query的性能影响很大，所以我们更应该深入理解 MySQL 中索引的基本实现，以及不同索引之间的区别，这样才能分析出如何设计最优的索引，最大幅度地提升Query的执行效率。

在 MySQL 中，主要有4种类型的索引，分别为：B-Tree 索引、Hash索引、Fulltext 索引和 R-Tree 索引，下面针对这4种索引的基本实现方式及存储结构做一个大概的分析。

8.4.1  B-Tree 索引

B-Tree 索引是 MySQL 数据库中使用最为频繁的索引类型，除了 Archive 存储引擎之外的其他所有的存储引擎都支持 B-Tree 索引。不仅在MySQL 中是如此，在其他的很多数据库管理系统中 B-Tree 索引也同样是作为最主要的索引类型的，这主要是因为 B-Tree索引的存储结构在数据库的数据检索中有着非常优异的表现。

一般来说，MySQL 中的 B-Tree 索引的物理文件大多是以 Balance Tree 的结构来存储的，也就是所有实际需要的数据都存放于 Tree 的Leaf Node，而且到任何一个 Leaf Node的最短路径的长度都是完全相同的，所以把它称之为 B-Tree 索引。不过，可能各种数据库（或 MySQL 的各种存储引擎）在存放自己的 B-Tree 索引的时候会对存储结构稍作改造。如 InnoDB 存储引擎的 B-Tree 索引使用的存储结构实际上是 B+Tree，在 B-Tree 数据结构的基础上做了很小的改造，在每一个 Leaf Node 上面除了存放索引键的相关信息之外，还存储了指向与该 Leaf Node 相邻的后一个 Leaf Node 的指针信息，这主要是为了加快检索多个相邻 Leaf Node 的效率。

在 InnoDB 存储引擎中，存在两种不同形式的索引，一种是 Cluster 形式的主键索引（Primary Key），另外一种则是和其他存储引擎（如MyISAM存储引擎）存放形式基本相同的普通 B-Tree 索引，这种索引在 InnoDB 存储引擎中被称为 Secondary Index。下面通过图8-1针对这两种索引的存放形式做一个比较。

图8-1左侧为Clustered 形式存放的 Primary Key，右侧则为普通的 B-Tree 索引。两种索引在 Root Node 和Branch Nodes 方面完全一样。但它们会在Leaf Nodes方面出现差异。在 Primary Key 中，Leaf Nodes 存放的是表的实际数据，不仅仅包括主键字段的数据，还包括其他字段的数据，整个数据以主键值有序的排列。而 Secondary Index 则和其他普通的 B-Tree 索引没有太大的差异，只是在 Leaf Nodes除了存放索引键的相关信息外，还存放了 InnoDB 的主键值。

所以，在 InnoDB 中如果通过主键来访问数据效率是非常高的，而如果是通过 Secondary Index 来访问数据的话，InnoDB 首先通过 Secondary Index 的相关信息及相应的索引键检索到 Leaf Node，再通过Leaf Node 中存放的主键值和主键索引来获取相应的数据行。

（点击查看大图）图8-1

MyISAM 存储引擎的主键索引和非主键索引差别很小，只不过主键索引的索引键是一个唯一且非空的键。而且 MyISAM 存储引擎的索引和 InnoDB 的 Secondary Index 的存储结构基本相同，主要的区别只是 MyISAM 存储引擎在 Leaf Nodes 上除了存放索引键信息之外，还存放能直接定位到 MyISAM 数据文件中相应数据行的信息（如Row Number），但并不会存放主键的键值信息。