Schema的优化和索引 - 索引的基础 - 索引的类型 - B-Tree索引

索引有许多类型，它们都是针对不同的用途而被设计的。索引是在存储引擎中实现的，而不是服务器。因此它们并没有标准化：在每个引擎中，索引工作的方式都有所不同，并且并不是所有的存储引擎支持所有种类的索引。即使这些存储引擎支持索引的类型相同，在底层的实现也是有所不同。

让我们来看看MySQL所支持的索引类型，它们的优势和缺点。

B-Tree索引

当人们讨论索引而没有说明它的类型的时候，往往指的是B-Tree索引。它用B-Tree数据结构存储了数据。大部分MySQL存储引擎都支持这种类型。Archive引擎是个例外：MySQL5.1之前还不支持索引，现在可以支持对AUTO_INCREMENT列添加一个索引了。

对于这些索引，我们使用术语B-TREE，那是因为在CREATE TABLE和其他语句中MySQL都是这么使用它们的。然而，存储引擎内部可能使用不同的存储结构。比如，NDB集群存储引擎使用T-TREE的结构来实现这些索引的。

存储引擎在硬盘上存储B-TREE索引的方式也各不相同。这些方式会影响性能。举个实例，MyISAM使用前缀压缩技术使索引变得更小。然而InnoDB并没有压缩索引，因为它的一些优化功能不能使用压缩的索引。MyISAM还通过行所存储的物理位置来引用这个已索引的行，但是InnoDB是通过主键值来引用它们的。每种方式都有各自的优点和缺点。

B-Tree的普通思路是，有序的存储所有的值，并且每个叶的页面(leaf page)和根节点都是相同的距离。下面的图是抽象的B-Tree索引的展现。这和InnoDB索引的工作方式有点相吻合。（InnoDB使用的是B+TREE结构）。MyISAM使用不同的结构，但是概念上是相似的。

因为存储引擎不必为了查找所需的数据而检索这张表，所以一个B-Tree的索引能加快数据的访问。相反，它是从根节点开始查找。（图中并没有表示）。根节点的槽（slots）保存了指向子节点的指针，并且此存储引擎也关注这些指针。它通过 查看节点页面的值来找到正确的指针。在子节点中定义了值的最大和最小的范围。最终，存储引擎就会知道查找的值是否存在。

叶的页面（leaf page）是特殊的，因为它们有指针指向索引数据，而不是指向其他页。（不同的存储引擎有不同的指针类型指向数据）。我们的例子展示了只有一个节点页和它的页的页面(leaf page)，但是实际上在根节点和叶之间有很多级别的节点。树的深度取决于表的大小。

因为B-Trees存储了有序的索引列。所以对于搜索某一范围的数据是很有用的。来看一个示例，来看一个文本字段加上一个以字母顺序排序的索引的层级树，因此来查询“首字母的范围是I到K的用户”效率是非常高的。

假使表的结构如下：

CREATE TABLE People (

last_name varchar(50) not null,

first_name varchar(50) not null,

dob date not null,

gender enum('m', 'f') not null,

key(last_name, first_name, dob)

);

索引包含的每一行的last_name,first_name,dob列的值。存储的图如下：

要注意的是，索引存储的值的顺序是在表定义的时候所给定的列的顺序。来看看最后两个实体：这两个人有相同的名字，而生日不同，因此他们是通过生日来存储的。

（编辑：云计算网_泰州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!