Schema的优化和索引 - 高性能的索引策略 - 聚簇索引1

Schema的优化和索引 - 高性能的索引策略 - 聚簇索引1

　聚簇索引并不是一个独立的索引类型。确切的说它们是存储数据的一个途径。在不同实现之间，还是有一些细节上的变化，但是InnoDB的聚簇索引实际是在相同的结构中把B-TREE索引和这些行一并的存储。

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

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

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

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

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

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