Mysql中的聚簇索引cluster index解析

聚簇索引（cluster index）

一个表只能有一个聚簇索引。

目前，只有solidDB和InnoDB支持聚簇索引，MyISAM不支持聚簇索引。一些DBMS允许用户指定聚簇索引，但是MySQL的存储引擎到目前为止都不支持。

InnoDB的聚簇索引：

• InnoDB对主键建立聚簇索引。
• 如果你不指定主键，InnoDB会用一个具有唯一且非空值的索引来代替。
• 如果不存在这样的索引，InnoDB会定义一个隐藏的主键，然后对其建立聚簇索引

InnoDB默认使用聚簇索引来组织数据，如果你用InnoDB，而且不需要特殊的聚簇索引，一个好的做法就是使用代理主键（surrogate key）—独立于你的应用中的数据。最简单的做法就是使用一个AUTO_INCREMENT的列，这会保证记录按照顺序插入，而且能提高使用primary_key进行连接的查询的性能。应该尽量避免随机的聚簇主键，例如字符串主键就是一个不好的选择，它使得插入操作变得随机

变得随机的不好的地方

聚簇索引保证关键字的值相近的元祖存储的物理位置也相近（所以字符串类型不宜简历聚簇索引，特别是随机字符串，会使系统进行大量的移动操作）

一般来说，DBMS都会以聚簇索引的形式来存储实际的数据，它是其他二级索引的基本：

• 聚簇索引（primary索引）：主键索引
• 非聚簇索引（second索引）：二级索引 聚簇索引的结构：

聚簇索引的结构：

节点页只包含了索引列，叶子页包含了行的全部数据。聚簇索引“就是表”，因此可以不需要独立的行存储

二级索引：叶子节点保存的不是指行的物理位置的指针，而是行的主键值 。

这意味着通过二级索引查找行，存储引擎需要：

1. 找到二级索引的叶子节点获得对应的主键值
2. 根据这个主键值去聚簇索引中查找对应的行。这里需要两次B-Tree查找而不是一次。

覆盖索引对于InnoDB表尤其有用，因为InnoDB使用聚簇索引组着数据，如果二级索引中包含查询所需的数据，就不再需要在聚集索引中查找了。

聚簇索引（InnoDB）和二级索引（MyISAM）

数据布局比较：

CREATE TABLE layout_test (
  col1 int NOT NULL,
  col2 int NOT NULL,
  PRIMARY KEY(col1),
  KEY(col2)
);

MyISAM

MyISAM按照插入的顺序在磁盘上存储数据：

左边为行号（row number），从0开始。因为元组的大小固定，所以MyISAM可以很容易的从表的开始位置找到某一字节的位置。

MyISAM建立的索引结构大致如下：

cod1主键索引：

MyISAM不支持聚簇索引，索引中每一个叶子节点仅仅包含行号（row number），且叶子节点按照col1的顺序存储。

col2非主键索引：

在MyISAM中，primary key和其他索引没有什么区别。Primary key仅仅只是一个叫做PRIMARY的唯一，非空的索引而已，叶子节点按照col2的顺序存储。

InnoDB：

col1主键索引，即聚簇索引：

聚簇索引中的每个叶子节点包含主键的值，事务ID,用于事务和MVVC的回滚指针、余下的列

col2非主键索引，及二级索引

InnoDB的二级索引的叶子包含主键的值，而不是行指针（row pointers），这样的策略减小了移动数据或者数据页面分裂时维护二级索引的开销，因为InnoDB不需要更新索引的行指针。

到此这篇关于Mysql中的聚簇索引cluster index解析的文章就介绍到这了,更多相关Mysql聚簇索引内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！