InnoDB 聚簇索引

InnoDB使用的是聚簇索引，将主键组织到一棵B+树中，而行数据就储存在叶子节点上，若使用"where id = 14"这样的条件查找主键，则按照B+树的检索算法即可查找到对应的叶节点，之后获得行数据。
若对Name列进行条件搜索，则需要两个步骤：第一步在辅助索引B+树中检索Name，到达其叶子节点获取对应的主键。第二步使用主键在主索引B+树种再执行一次B+树检索操作，最终到达叶子节点即可获取整行数据。（重点在于通过其他键需要建立辅助索引）

聚簇索引的优势

看上去聚簇索引的效率明显要低于非聚簇索引，因为每次使用辅助索引检索都要经过两次B+树查找，这不是多此一举吗？聚簇索引的优势在哪？

由于行数据和叶子节点存储在一起，同一页中会有多条行数据，访问同一数据页不同行记录时，已经把页加载到了Buffer中，再次访问的时候，会在内存中完成访问，不必访问磁盘。这样主键和行数据是一起被载入内存的，找到叶子节点就可以立刻将行数据返回了，如果按照主键 ID 来组织数据，获得数据更快。
辅助索引使用主键作为"指针"而不是使用地址值作为指针的好处是，减少了当出现行移动或者数据页分裂时辅助索引的维护工作，使用主键值当作指针会让辅助索引占用更多的空间，换来的好处是InnoDB在移动行时无须更新辅助索引中的这个"指针"。也就是说行的位置（实现中通过16K的Page来定位）会随着数据库里数据的修改而发生变化（前面的B+树节点分裂以及Page的分裂），使用聚簇索引就可以保证不管这个主键B+树的节点如何变化，辅助索引树都不受影响。
聚簇索引适合用在排序的场合，非聚簇索引不适合
取出一定范围数据的时候，使用用聚簇索引
二级索引需要两次索引查找，而不是一次才能取到数据，因为存储引擎第一次需要通过二级索引找到索引的叶子节点，从而找到数据的主键，然后在聚簇索引中用主键再次查找索引，再找到数据
可以把相关数据保存在一起。例如实现电子邮箱时，可以根据用户 ID 来聚集数据，这样只需要从磁盘读取少数的数据页就能获取某个用户的全部邮件。如果没有使用聚簇索引，则每封邮件都可能导致一次磁盘 I/O。

聚簇索引的劣势

维护索引很昂贵，特别是插入新行或者主键被更新导至要分页(page split)的时候。建议在大量插入新行后，选在负载较低的时间段，通过OPTIMIZE TABLE优化表，因为必须被移动的行数据可能造成碎片。使用独享表空间可以弱化碎片
表因为使用UUId（随机ID）作为主键，使数据存储稀疏，这就会出现聚簇索引有可能有比全表扫面更慢，

image

所以建议使用int的auto_increment作为主键

image

主键的值是顺序的，所以 InnoDB 把每一条记录都存储在上一条记录的后面。当达到页的最大填充因子时（InnoDB 默认的最大填充因子是页大小的 15/16，留出部分空间用于以后修改），下一条记录就会写入新的页中。一旦数据按照这种顺序的方式加载，主键页就会近似于被顺序的记录填满（二级索引页可能是不一样的）

如果主键比较大的话，那辅助索引将会变的更大，因为辅助索引的叶子存储的是主键值；过长的主键值，会导致非叶子节点占用占用更多的物理空间

为什么主键通常建议使用自增id

聚簇索引的数据的物理存放顺序与索引顺序是一致的，即：只要索引是相邻的，那么对应的数据一定也是相邻地存放在磁盘上的。如果主键不是自增id，那么可以想象，它会干些什么，不断地调整数据的物理地址、分页，当然也有其他一些措施来减少这些操作，但却无法彻底避免。但，如果是自增的，那就简单了，它只需要一页一页地写，索引结构相对紧凑，磁盘碎片少，效率也高。

因为MyISAM的主索引并非聚簇索引，那么他的数据的物理地址必然是凌乱的，拿到这些物理地址，按照合适的算法进行I/O读取，于是开始不停的寻道不停的旋转。聚簇索引则只需一次I/O。（强烈的对比）

不过，如果涉及到大数据量的排序、全表扫描、count之类的操作的话，还是MyISAM占优势些，因为索引所占空间小，这些操作是需要在内存中完成的。

mysql中聚簇索引的设定

聚簇索引默认是主键，如果表中没有定义主键，InnoDB 会选择一个唯一的非空索引代替。如果没有这样的索引，InnoDB 会隐式定义一个主键来作为聚簇索引。InnoDB 只聚集在同一个页面中的记录。包含相邻健值的页面可能相距甚远。

MyISM 非聚簇索引

MyISM使用的是非聚簇索引，非聚簇索引的两棵B+树看上去没什么不同，节点的结构完全一致只是存储的内容不同而已，主键索引B+树的节点存储了主键，辅助键索引B+树存储了辅助键。表数据存储在独立的地方，这两颗B+树的叶子节点都使用一个地址指向真正的表数据，对于表数据来说，这两个键没有任何差别。由于索引树是独立的，通过辅助键检索无需访问主键的索引树。

Kotlin 开发者社区

国内第一Kotlin 开发者社区公众号，主要分享、交流 Kotlin 编程语言、Spring Boot、Android、React.js/Node.js、函数式编程、编程思想等相关主题。

越是喧嚣的世界，越需要宁静的思考。

合抱之木，生于毫末；
九层之台，起于垒土；
千里之行，始于足下。
积土成山，风雨兴焉；
积水成渊，蛟龙生焉；
积善成德，而神明自得，圣心备焉。
故不积跬步，无以至千里；
不积小流，无以成江海。
骐骥一跃，不能十步；
驽马十驾，功在不舍。
锲而舍之，朽木不折；
锲而不舍，金石可镂。
蚓无爪牙之利，筋骨之强，上食埃土，下饮黄泉，用心一也。
蟹六跪而二螯，非蛇鳝之穴无可寄托者，用心躁也。

聚簇索引与非聚簇索引相关推荐

mysql 聚簇索引和非聚簇索引_聚簇索引和非聚簇索引
聚簇索引并不是一种单独的索引类型,而是一种数据存储方式.具体细节依赖于其实现方式. MySQL数据库中innodb存储引擎,B+树索引可以分为聚簇索引(也称聚集索引,clustered index)和 ...
聚簇索引与非聚簇索引学习总结
聚簇索引与非聚簇索引的区别通常情况下,建立索引是加快查询速度的有效手段.但索引不是万能的,靠索引并不能实现对所有数据的快速存取.事实上,如果索引策略和数据检索需求严重不符的话,建立索引反而会降低查 ...
聚簇索引、非聚簇索引、普通索引、唯一索引
一.聚簇索引 VS 非聚簇索引聚簇索引:将数据存储与索引放到了一块,找到索引也就找到了数据非聚簇索引:将数据存储于索引分开结构,索引结构的叶子节点指向了数据的对应行,myisam通过key_buf ...
浅析聚簇索引与非聚簇索引（也叫二级索引）
通俗点讲聚簇索引:将数据存储与索引放到了一块,找到索引也就找到了数据非聚簇索引:将数据存储于索引分开结构,索引结构的叶子节点指向了数据的对应行,myisam通过key_buffer把索引先缓存到内 ...
mysql 聚簇索引和非聚簇索引_MySQL学习之——索引
转自:CSDN MySQL是目前绝大多数互联网公司使用的关系型数据库,它性能出色.资源丰富.成本低廉,是快速搭建互联网应用的首选关系型数据库.但是,俗话说,"好马配好鞍",仅仅会使 ...
mysql 聚簇索引和非聚簇索引_图文并茂，说说MySQL索引
点击上方小伟后端笔记 ,选择星标公众号重磅资讯.干货,第一时间送达作者:小小木的博客来源:cnblogs.com/wyc1994666/p/10831039.html 序开门见山,直接上图 ...
在mysql中建立聚簇索引_给我一分钟，让你彻底明白MySQL聚簇索引和非聚簇索引...
推荐阅读:吊打面试官!MySQL灵魂100问,你能答出多少? MySQL的InnoDB索引数据结构是B+树,主键索引叶子节点的值存储的就是MySQL的数据行,普通索引的叶子节点的值存储的是主键值,这是 ...
聚簇索引和非聚簇索引详解
通俗点讲聚簇索引:将数据存储与索引放到了一块,找到索引也就找到了数据非聚簇索引:将数据存储于索引分开结构,索引结构的叶子节点指向了数据的对应行,myisam通过key_buffer把索引先缓存到内 ...
mysql 聚簇_mysql索引总结(3)-MySQL聚簇索引和非聚簇索引
非聚簇索引索引节点的叶子页面就好比一片叶子.叶子头便是索引键值. 先创建一张表: CREATE TABLE `user` ( `id`INT NOT NULL, `name`VARCHAR NOT ...
java中簇如何表示_聚簇索引和非聚簇索引实际上是什么意思？
我对DB的接触有限,只使用DB作为应用程序程序员. 我想了解Clustered和Non clustered indexes . 我搜索了一下,发现的是: 聚集索引是一种特殊的索引,它重新排序表中记录的 ...

聚簇索引与非聚簇索引