Schema的优化和索引 - 高性能的索引策略 - 聚簇索引(Clustered Indexes)

核心提示： 每个叶子节点都包含了已索引的列（这里是col2），紧跟着它的就是主键值（col1），Schema的优化和索引 - 高性能的索引策略 - 聚簇索引(Clustered Indexes)(5)，这个图的事例是B-Tree叶子节点，但是我们忽略了不是叶子的节点，为了演示这个，我们测试两个例子，Inno

每个叶子节点都包含了已索引的列（这里是col2），紧跟着它的就是主键值（col1）。

这个图的事例是B-Tree叶子节点，但是我们忽略了不是叶子的节点。InnoDB不是B-TREE节点包含了已索引的列，加上指向更深层次的节点的指针（既可能是叶子节点也可能不是叶子节点）。以上说的适用于所有的索引，聚簇索引和次要索引。

下面的图是抽象的InnoDB和MyISAM数据的分布。更清晰的可以看到InnoDB和MyISAM存储数据和索引的不同。

如果你还不明白聚簇和非聚簇索引的的不同以及它们的重要性，请不要担心。在以后的讲解中会逐渐的清晰。在以后的章节中，例子会更加的复杂。需要用一些来更好的理解它们。

InnoDB中按照主键的顺序来插入行。

如果你使用的是InnoDB并且不需要特殊的聚簇。定义一个代理键（surrogate key）是个好的主意。意思就是这个主键并不是来自于你的应用程序的数据。最简单的方法就是使用AUTO_INCREMENT列。这能保证数据插入保持着连续的顺序并且对于使用主键连接会获得更好的性能。

最好避免使用随机的聚簇键。比如，从性能的角度来说，使用UUID是个不好的方法：它使聚簇索引的插入是随机的。这是最不好的场景了。并且对于数据的聚集也没有什么帮助。

为了演示这个，我们测试两个例子。第一个使用integerID插入一个userinfo。userinfo表定义如下

CREATE TABLE userinfo (

id int unsigned NOT NULL AUTO_INCREMENT,

name varchar(64) NOT NULL DEFAULT '',

email varchar(64) NOT NULL DEFAULT '',

password varchar(64) NOT NULL DEFAULT '',

dob date DEFAULT NULL,

address varchar(255) NOT NULL DEFAULT '',

city varchar(64) NOT NULL DEFAULT '',

state_id tinyint unsigned NOT NULL DEFAULT '0',

zip varchar(8) NOT NULL DEFAULT '',

country_id smallint unsigned NOT NULL DEFAULT '0',

gender ('M','F') NOT NULL DEFAULT 'M',

account_type varchar(32) NOT NULL DEFAULT '',

verified tinyint NOT NULL DEFAULT '0',

allow_mail tinyint unsigned NOT NULL DEFAULT '0',

parrent_account int unsigned NOT NULL DEFAULT '0',

closest_airport varchar(3) NOT NULL DEFAULT '',

PRIMARY KEY (id),

UNIQUE KEY email (email),

KEY country_id (country_id),

KEY state_id (state_id),

KEY state_id_2 (state_id,city,address)

) ENGINE=InnoDB