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

当一个表中有聚簇索引，它的行实际存储在索引的叶子的页（leaf pages）。“clustered”所指的意思是行的相邻键值彼此存储的非常近。你可能每张表只会有一个聚簇索引，因为你不能同时的在两个地方存储这些行。

因为存储引擎负责实现索引，因此并不是所有的存储引擎都支持聚簇索引。目前来说，solidDB和InnoDB支持。这部分我们重点放在InnoDB上，但是对于那些已经实现或者将要实现聚簇索引的引擎来说，在概念上至少有部分的正确。

下图展示了记录是怎样分布在聚簇索引上的。注意的是叶子的页（leaf pages）包含了整个行，但是节点的页仅仅包含了索引的列。这个例子中，索引列包含了整型值。

一些数据库服务器使你可以选择哪个索引可以聚簇，但是MySQL目前的存储引擎是不能那么做的。InnoDB通过主键来集中数据的。也就是说上图的索引列就是主键列。

如果你没有定义主键，InnoDB会选择一个唯一非空的索引来替代主键索引。如果没有这么个索引，InnoDB就会定义一个隐藏的主键。InnoDB仅仅在一个页中聚集数据。页所伴随的临近的键值可能彼此相互远离。

一个聚簇主键索引对性能有所帮助，但是也可能会导致严重的性能问题。因此，你应该仔细的思考聚簇，尤其是当你改变一个表的存储引擎从InnoDB转为其他的引擎。

聚簇数据有很多重要的优势。

能使相关联的数据距离很近。比如，当要实现一个mailbox，你可以通过user_id来聚簇，因此你能通过获取硬盘上一小部分的页来获得一个单独用户的所有消息。如果你不做聚簇，那么每个消息可能都需要各自的硬盘I/O。

数据访问更加快速。一个聚簇索引在B-TREE上即保存了索引也保存了数据。因此从聚集索引获取行一般要快于在非聚集索引中比较查找。

使用覆盖索引的语句可以使用包含在叶子节点的主键值。

如果你设计表和语句的时候好好利用它们，对性能的提高大有帮助。然而聚簇索引也有很多缺点

聚簇会大幅提高IO限制（IO-BOUND）工作量。如果数据在内存中的顺序对数据的访问并不是什么问题的话，聚簇就不能带来那么多好处了。

插入的顺序影响插入的速度。按照主键的速度插入行是最快的读入数据到InnoDB表的方法。如果你没有依照主键的顺序来读取数据，那么在读取很多数据之后，使用OPTIMIZE TABLE来重新组织表是个很好的主意。

更新聚簇索引的列消耗是非常高的。因为它迫使InnoDB把每一行移动到新的位置。

当新的一行插入或行的主键更新，这样会导致聚簇索引的页的分裂。当一个行的键值决定了该行以及它所有的数据一定要放在一页里的时候，页的分裂就发生了。因为存储引擎必须把页分为两个来容纳这个行。页的分裂会导致表占用更多的空间。

聚簇的表会降低检索整张表的速度。尤其是在由于页的分裂，造成行没有被压缩或者没有连续的存储的情况下，问题就很严重。

非聚簇索引可能比你所想像的要大很多。因为它们的叶子节点包含了它们引用行的主键列。

非聚簇索引的访问需要两个索引的查找。

最后的一条可能有些困惑，为什么非聚簇索引需要两次索引的查找？答案就隐藏在非聚簇索引所存储的“行指针”上。记住一个叶子节点存储的指针并不是引用行的物理地址，而是存储了行的主键值。

意思就是从非聚簇索引中查找一行，首先，存储引擎会在非聚簇索引找到叶子节点并且之后只用它所存储的主键值找到主键并且找到这个行。这是个双重工作：两个B-TREE的导航。

（编辑：济南站长网）

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