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

核心提示： 要注意主键是自增的，第二个例子的表命名为userinfo_uuid，Schema的优化和索引 - 高性能的索引策略 - 聚簇索引(Clustered Indexes)(6)，和userinfo唯一的区别就是主键是UUID的，CREATE TABLE userinfo_uuid (uuid var

要注意主键是自增的。

第二个例子的表命名为userinfo_uuid。和userinfo唯一的区别就是主键是UUID的。

CREATE TABLE userinfo_uuid (

uuid varchar(36) NOT NULL,

我们对两个表做基准测试。首先我们对两个表插入100W数据。这个时候有足够的内存来存放索引。第二次我们插入300W数据，索引已经超出了内存的大小了。如下就是两个数据的比较

我们发现UUID作为主键的表不仅插入速度慢，而且索引还非常的大。一些原因是由于主键变大，而另一些原因不用怀疑的就是页的分裂和产生的一些碎片。

为了说明为什么会这样，让我们来看看当我们插入第一张表的时候，在索引中发生了些什么状况。

因为新行的主键并不是必须的比前一个主键值要大，因此InnoDB不能总是把新行放到这个索引之后。必须要为新行找到一个合适的位置-平均位置，也就是在靠近已存在数据的中部为新的数据生成一个空间。这就导致了一些额外的工作以及不理想的数据布局。下面就是一些缺陷：

1.目标页要刷新到硬盘并且要清除缓存。这个例子中，InnoDB在插入新行之前，要找到它和从硬盘中读取它。这就导致了很多的随机IO。

2.InnoDB有的时候会分裂页，这样做的目的是为新行创建空间。这需要移动很多的数据。

3.因为页的分裂，页会变得稀疏并且不规则的填充。因此最终数据是碎片的。

在读取许多随机值到聚簇索引中之后，你应该使用OPTIMIZE TABLE语句重新构建表并且优化的填充页。

这个例子告诉我们在使用InnoDB的时候要尽可能的顺序的插入数据，并且使用增长的聚簇索引。