聚簇索引并非一种零丁的索引范例，而是一种数据存储体式格局（不是数据构造，而是存储构造），细致细节依赖于其完成体式格局，但innodb的聚簇索引实际上是在同一个构造中保留了btree索引和数据行。
当表有索引时，它的数据行实际上存放在索引的叶子页中，属于聚簇示意数据行和相邻的键值紧凑地存储在一起，因为没法同时把数据行存放在两个差别的处所，所以一个表只能有一个聚簇索引。因为是存储引擎担任完成索引，因而不是一切的存储引擎都支撑聚簇索引。下面主要引见innodb，但下面议论的道理关于任何支撑聚簇索引的引擎都实用：
叶子页包括了行的悉数数据，然则节点页只包括了索引列（或许能够说非叶子节点的节点页包括的是索引值的索引，因为这些节点页包括的值是从索引列中提取出来的）。
innodb将经由过程主键群集数据，假如没有定义主键，Innodb会挑选第一个非空的唯一索引替代，假如没有非空唯一索引，Innodb会隐式定义一个6字节的rowid主键来作为群集索引。innodb只群集在同一个页面中的纪录，包括相邻键值的页面能够会相距甚远。
要注意：聚簇主键能够对机能有协助，但也能够致使严峻的机能题目，尤其是将表的存储引擎从innodb转换成其他引擎的时刻。
群集的数据有一些主要的长处：
A：能够把相干数据保留在一起，如：完成电子邮箱时，能够依据用户ID来群集数据，如许只须要从磁盘读取少许的数据页就可以猎取某个用户悉数邮件，假如没有运用群集索引，则每封邮件都能够致使一次磁盘IO
B：数据接见更快，群集索引将索引和数据保留在同一个btree中，因而从群集索引中猎取数据一般比在非群集索引中查找要快
C：运用掩盖索引扫描的查询能够直接运用页节点中的主键值
群集索引的瑕玷：
A：聚簇数据最大限制地提高了IO密集型运用的机能，但假如数据悉数放在内存中，则接见的递次就没有那末主要了，群集索引也没有什么上风了
B：插进去速率严峻依赖于插进去递次，根据主键的递次插进去是加载数据到innodb表中速率最快的体式格局，但假如不是根据主键递次加载数据，那末在加载完成后最好运用optimize table敕令从新组织一下表
C：更新群集索引列的价值很高，因为会强迫innodb将每一个被更新的行挪动到新的位置
D：基于群集索引的表在插进去新行，或许主键被更新致使须要挪动行的时刻，能够面对页破裂的题目，当行的主键值请求必须将这一行插进去到某个已满的页中时，存储引擎会将该页破裂成两个页面来包容该行，这就是一次页破裂操纵，页破裂会致使表占用更多的磁盘空间
E：群集索引能够致使全表扫描变慢，尤其是行比较希罕，或许因为页破裂致使数据存储不一连的时刻
F：二级索引能够比设想的更大，因为在二级索引的叶子节点包括了援用行的主键列。
G：二级索引接见须要两次索引查找，而不是一次
因为二级索引叶子节点中保留的不是指向行的物理位置的指针，而是行的主键值。这意味着经由过程二级索引查找行，存储引擎须要找到二级索引的叶子节点取得对应的主键值，然后依据这个主键值去群集索引中查找对应的行，这里做了反复的事情，两次btree查找而不是一次，关于innodb，自适应哈希索引能削减如许的反复事情。
innodb和myisam物理存储的数据散布对照：
myisam：
是根据数据插进去的递次存储在磁盘上的，myisam中的主键索引和二级索引在构造上并没有什么差别，主键索引就是一个名为primary的唯一非空索引。
innodb：
因为innodb支撑群集索引，所以运用异常差别的体式格局存储一样的数据，innodb群集索引包括了全部表的数据，而不是只要索引，因为在Innodb中，群集索引就是表，所以不像myisam那样须要自力的行存储。群集索引的每一个叶子节点都包括了主键值，事件ID，用于事件和MVCC的回滚指针以及一切盈余列的值，假如主键是一个列前缀索引，innodb也会包括完整的主键列和剩下的列的值。
另有一点和myisam差别的是，innodb的二级索引和群集索引很差别，innodb二级索引的叶子节点中存储的不是行指针，而是主键值，并以此作为指向行的指针，如许的战略削减了当出现行挪动或许数据页的破裂时二级索引的保护事情，运用主键值当作指针会让二级索引占用更多的空间，换来的优点是，innodb在挪动行时不必更新二级索引中的这个指针。
在innodb表中按主键递次插进去行，假如正在运用Innodb表而且没有什么数据须要群集，那末能够定义一个代办键作为主键，这类主键的数据应当和运用无关，最简朴的要领是运用auto_increment自增列，如许能够保证数据行是按递次插进去的，关于依据主键做关联操纵的机能也会更好。
不要运用UUID来作为群集索引，不然机能会很蹩脚，因为它使得群集索引的插进去变得完整随机，使得数据没有任何群集特征。因为UUID作为主键插进去行不仅消费的时候更长，而且索引也更大，这一方面是因为主键字段变长了，别的一方面毫无疑问是因为页破裂致使时候变长和碎片致使的索引变大。因为主键的值是递次的，所以Innodb把每一条纪录都存储在上一条纪录的背面，当到达页的最大添补因子时（innodb默许的最大添补因子是页大小的十六分之十五，留出部份空间用于今后修正），下一条纪录就会写入新的页中，一旦数据根据这类递次的体式格局加载，主键页就会近似被递次的纪录填满，这也恰是所希冀的效果（但是，二级索引页多是不一样的）。
在UUID主键下，因为新插进去行的主键值不一定比前面的大，所以innodb没法简朴地老是把新行插进去到索引的末了，而是须要为新的行寻觅适宜的位置，一般是已有数据的中心位置，而且分派新的空间，这会增添许多分外的事情，并致使数据散布不够优化，下面是运用UUID作为主键的一些瑕玷：
A：写入的目的页能够已刷到磁盘上并从缓存中移除，或许是还没有被加载到缓存中，innodb在插进去前不能不先找到并从磁盘读取目的页到内存中，这将致使大批的随机IO
B：因为写入是乱序的，innodb不能不频仍地做页破裂操纵，以便为新的行分派空间，页破裂会致使挪动大批数据，一次插进去起码须要修正三个页不是一个页
C：因为频仍的页破裂，页会变得希罕并被不规则地添补，所以终究数据会有碎片
把这些随机值载入到群集索引以后，或许须要做一次optimize table来重修表并优化页的添补。运用innodb时应当尽量地根据主键递次插进去数据，而且尽量地运用简朴增添的聚簇键的值来插进去新行。
注：递次的主键什么时刻会形成更坏的效果？
关于高并发事情负载，在Innodb中按主键递次插进去能够会形成显著的争用，主键的上界会称为热门，因为一切的插进去都发生在这里，所以并发插进去能够致使间隙锁争用，另一个热门多是auto_increment锁机制，假如碰到这个题目，则能够须要从新设想表或许运用，或许变动innodb_autoinc_lock_mode设置。
以上就是mysql群集索引的有哪些瑕玷的细致内容，更多请关注ki4网别的相干文章！
