这篇文章主要介绍“数据库的聚簇索引是什么”，在日常操作中，相信很多人在数据库的聚簇索引是什么问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”数据库的聚簇索引是什么”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！
聚簇索引并不是一种单独的索引类型，而是一种数据存储方式。具体的细节依赖于其实现方式，但InnoDB的聚簇索引实际上在同一个结构中保存了B-Tree索引和数据行，即聚簇索引就是表。当表有聚簇索引时，它的数据行实际上存放在索引的叶子页中，术语聚簇表示数据行和相邻的键值紧凑地存储在一起。因为无法同时把数据行存放在两个不同的地方，所以一个表只能有一个聚簇索引。因为是存储引擎负责实现索引，因此不是所有的存储引擎都支持聚簇索引。如下图为聚簇索引的数据分布，叶子页包含了行的全部数据，但是节点页只包含了索引列。
图-聚簇索引的数据分布
InnoDB通过主键聚集数据，如果没有定义主键，InnoDB会选择一个唯一的非空索引代替，如果没有这样的索引，InnoDB会隐式定义一个主键来作为聚簇索引。聚簇主键可能对性能有帮助，但也可能导致严重的性能问题。但是目前MySQL内建的存储引擎暂时不支持选择哪个索引作为聚簇索引。
聚簇的数据有一些重要的优点：
可以将相关数据保存在一起，例如实现电子邮箱时，可以根据用户id来聚集索引，这样只需要从磁盘读取少量的数据页就能获得某个用户的全部邮件，如果没有使用聚簇索引，则每封邮件都可能导致一次磁盘I/O；
数据访问更快。聚簇索引将索引和数据保存在同一个B-Tree中，因此从聚簇索引中获取数据通常比在非聚簇索引中查找更快；
使用覆盖索引扫描的查询可以直接使用页节点中的主键值；
如果在设计表和查询时能充分利用上面的优点，那就能极大提升性能。同时聚簇索引也有一些缺点：
聚簇索引最大限度地提高了I/O密集型应用的性能，但如果数据全部都放在内存中，则访问的顺序就没那么重要了，聚簇索引也就没有什么优势了；
插入速度严重依赖于插入顺序。按照主键的方式顺序插入是速度最快的方式。但如果不是按照主键顺序加载数据，那么在加载完成后最好用optimize table命令重新组织一下表；
更新聚簇索引的代价很高，因为会强制InnoDB将每个被更新的行移到到新的位置；
基于聚簇索引的表在插入新行，或者主键被更新导致需要移动行的时候，可能面临页分裂的问题。当行的主键值要求必须将这一行插入到某个已满的页中时，存储引擎会将该页分裂成两个页面来容纳改行，这就是一次页分裂的操作，页分裂会导致表占用更多的磁盘空间；
聚簇索引可能导致全表扫描变慢，尤其是行比较稀疏，或者由于页分裂导致存储不连续的时候；
二级索引可能比想象的要更大，因为在二级索引的叶子节点包含了引用行的主键列；
二级索引访问需要两次索引查找而不是一次，二级索引中保存的不是指向行的物理位置的指针，而是行的主键值，这意味着通过二级索引查找行，存储引擎需要找到二级索引的叶子节点获得对应的主键值，然后根据这个值去聚簇索引中查找对应的行，这里做了重复的工作：两次B-Tree查找而不是一次。
聚簇索引和非聚簇索引的数据分布有区别，以及对应的主键索引和二级索引的数据分布也有区别。以下表为例进行分析对比：
CREATE TABLE `test` ( `id` int(11) NOT NULL, `last_name` char(30) NOT NULL, `first_name` char(30) NOT NULL, PRIMARY KEY (`id`), KEY `name` (`last_name`,`first_name`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
假设改表的主键取值为1-10000，按照随机的顺序插入并使用optimize table命令做了优化。换句话说，数据在磁盘上的存储方式已经最优，当行的顺序是最优的，列col2的值是从1-100之间随机赋值，所以有很多重复的值。
MyISAM的数据分布非常简单，按照数据插入的顺序存储在磁盘上，如下图所示，从行的旁边显示了行号，从0开始递增，因为行是定长的，所以MyISAM可以从表的开头跳过所需的字节找到需要的行（MyISAM并不总是使用图中的行号，而是根据定长还是变长的行使用不同的策略），这种分布方式很容易创建索引。下图简要显示MyISAM的主键分布，只显示了索引中的节点，索引中的每个叶子节点包含行号，col2列的索引和其它索引没有区别，事实上MyISAM主键索引和其它索引在结构上没有什么不同，主键索引就是一个名为PRIMARY的唯一非空索引。
图-MyISAM表layout_test的数据分布
图-MyISAM表的主键分布
图-MyISAM表col2列索引的分布
InnoDB的数据分布如下图所示，因为InnoDB支持聚簇索引，所以使用不同的方式存储相同的数据，会注意到该图显示了整个表，而不是只有索引，事实上，在InnoDB中聚簇索引就是表，所以不像MyISAM那样需要单独的行存储。聚簇索引的每个叶子节点都包含了主键值、事务ID、用于事务和MVCC的回滚指针以及所有的剩余列。如果主键是一个前缀索引，InnoDB也会包含完整的主键列和剩余的其它列。还有一点和MyISAM不同的是，InnoDB的二级索引和聚簇索引很不相同，InnoDB二级索引的叶子节点存储的不是“行指针”而是主键值，并以此作为指向行的“指针”。这样的策略减少了当出现行移动或者数据也分裂时二级索引的维护工作。使用主键值当作指针会让二级索引占用更多的空间，换来的好处是InnoDB在移动行时无需更新二级索引中的这个“指针”。
图-InnoDB表的主键分布
下图展示了InnoDB的二级索引结构，其中省略了一些细节，InnoDB的非叶子节点包含了索引列和一个指向下级节点的指针（下级节点可以是非叶子节点，也可以是叶子节点），每个叶子节点都包含了索引列（这里是col2），紧接着是主键列（col1）。
图-InnoDB的二级索引分布
下图是InnoDB和MyISAM如何存储表的抽象图，可以很容易看出二者保存数据和索引的区别：
图-聚簇和非聚簇索引对比图
可以看到InnoDB主索引是聚集索引，辅助索引是非聚集，存储的是主键值。 MyISAM索引是非聚集索引，辅助索引和主索引都是存的数据行地址。
如果正在使用的InnoDB表没有什么数据需要聚集，那么可以定义一个代理键作为主键，这种主键的数据应该和应用无关，最简单的办法就是使用自增列，这样可以保证数据行是按顺序写入，对于根据主键做关联操作的性能也会更好。最好避免随机的（不连续且值的分布范围非常大）聚簇索引，特别是对于I/O密集型的应用，例如从性能的角度来看，使用UUID来作为聚簇索引则会很槽糕：它使得聚簇索引的插入变得完全随机，这是最坏的情况，使得数据没有任何的聚集特性。可以做对比试验，自增id和UUID作为主键的性能对比，可以发现UUID主键插入行不仅花费的时间更长，而且索引占用的空间也更大，这样一方面是由于主键字段更长，另一方面是由于页分裂和碎片导致的。
图-向聚簇索引插入顺序的索引值
如上图所示，因为主键的值是顺序的，所以InnoDB把每一条记录都存储在上一条记录的后面。当达到页的最大填充因子时，下一条记录就会写入新的页中。一旦数据按照这种顺序的方式加载，主键页就会近似于被顺序的记录填满，这也会是所期望的结果（然而二级索引页可能是不一样的）。
对比一下使用UUID聚簇索引的表插入顺序，因为新行的主键值不一定比之前插入的大，所以InnoDB无法简单地总是把新行插入到索引的最后，而是需要为新的行寻找合适的位置-通常是已有数据的中间位置-并且分配空间，这会增加很多额外的工作，并导致数据分布不够优化。以下是总结的一些缺点：
写入的目标页可能已经刷入磁盘上并从缓存中移除，或者是还没有被加载到缓存中，InnoDB在插入之前不得不先找到并从磁盘读取目标页到内存中，这将导致大量的随机I/O；
因为写入是乱序的，InnoDB不得不频繁地做页分裂操作，以便为新的行分配空间。页分裂会导致移动大量数据，一次插入最少需要修改三个页而不是一个页；
由于频繁的页分裂，页会变得稀疏并不被规则地填充，所以最终数据会有碎片。
把这些随机值载入到聚簇索引后，也许需要做一次optimize table来重建表并优化页的填充。
图-向聚簇索引中插入无序的值
从这个案例可以看出，使用InnoDB时应该尽可能地按主键顺序插入数据，并且尽可能地使用单调递增的聚簇索引来载入新行。
顺序的主键什么时候会造成更坏的结果？
对于高并发工作负载，在InnoDB中按主键顺序插入可能会造成明显的争用。主键的上界会成为热点，因为所有的插入都发送在这里，所以高并发插入可能导致间隙锁竞争。另一个热点是AUTO_INCREMENT锁机制；如果遇到这个问题，则可以考虑重新设计表或者应用，或者更改innodb_autoinc_lock_mode配置。
到此，关于“数据库的聚簇索引是什么”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注亿速云网站，小编会继续努力为大家带来更多实用的文章！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
