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

核心提示： 聚簇数据有很多重要的优势，能使相关联的数据距离很近，Schema的优化和索引 - 高性能的索引策略 - 聚簇索引(Clustered Indexes)(2)，比如，当要实现一个mailbox，为什么非聚簇索引需要两次索引的查找？答案就隐藏在非聚簇索引所存储的“行指针”上，

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

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

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

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

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

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

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

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

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

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

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

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

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