????????但是 B 树的每个节点都包含数据（索引+记录），而用户的记录数据的大小很有可能远远超过了索引数据，这就需要花费更多的磁盘 I/O 操作次数来读到「有用的索引数据。而且，在我们查询位于底层的某个节点（比如 A 记录）过程中，「非 A 记录节点」里的记录数据会从磁盘加载到内存，但是这些记录数据是没用的，我们只是想读取这些节点的索引数据来做比较查询，而「非 A 记录节点」里的记录数据对我们是没用的，这样不仅增多磁盘 I/O 操作次数，也占用内存资源。
B+树
Mysql普遍使用B+树来实现其索引结构，跟B树相比，B+树有以下几个不同点
叶子节点（最底部的节点）才会存放实际数据（索引+记录），非叶子节点只会存放索引；
所有索引都会在叶子节点出现，叶子节点之间构成一个有序链表；
非叶子节点的索引也会同时存在在子节点中，并且是在子节点中所有索引的最大（或最小）。
非叶子节点中有多少个子节点，就有多少个索引；
????????B+ 树的非叶子节点不存放实际的记录数据，仅存放索引，因此数据量相同的情况下，相比存储即存索引又存记录的 B 树，B+树的非叶子节点可以存放更多的索引，因此 B+ 树可以比 B 树更「矮胖」，查询底层节点的磁盘 I/O次数会更少。
????????B+作为多叉树，在有大量的冗余节点，在进行删除或者插入操作时都不会发生复杂的树的变形。
????????在数据库中，还在B+树的基础上进行优化，增加了顺序访问指针。做这个优化的目的是为了提高区间访问的性能，例如如果要查询 key 为从 18 到 49 的所有数据记录，当找到 18 后，只需顺着节点和指针顺序遍历就可以一次性访问到所有数据节点，极大提到了区间查询效率。<br />而 B 树没有将所有叶子节点用链表串联起来的结构，因此只能通过树的遍历来完成范围查询，这会涉及多个节点的磁盘 I/O 操作，范围查询效率不如 B+ 树。因此，存在大量范围检索的场景，适合使用 B+树，比如数据库。而对于大量的单个索引查询的场景，可以考虑 B 树，比如 nosql 的MongoDB。
????????而在mysql中，B+ 树的叶子节点之间是用「双向链表」进行连接，这样的好处是既能向右遍历，也能向左遍历<br />?
聚集索引与二级索引
聚集索引（主键索引）：将数据与索引放到了一块，索引结构的叶子节点存储了行数据，找到索引也就找到了数据
二级索引（非主键索引）：将数据与索引分开存储，索引结构的叶子节点存储的是主键的值
InnoDB 在创建聚簇索引时，会根据不同的场景选择不同的列作为索引：
如果有主键，默认会使用主键作为聚簇索引的索引键；
如果没有主键，就选择第一个不包含 NULL 值的唯一列作为聚簇索引的索引键；
在上面两个都没有的情况下，InnoDB 将自动生成一个隐式自增 id 列作为聚簇索引的索引键；
因为表的数据都是存放在聚集索引的叶子节点里，所以 InnoDB 存储引擎一定会为表创建一个聚集索引，且由于数据在物理上只会保存一份，所以聚簇索引只能有一个，而二级索引可以创建多个。
例如图中(ID,k)值分别为(100,1)、(200,2)、(300,3)、(500,5)和(600,6)
???查询时的区别：
如果语句是select * from T where ID=500，即主键查询方式，则只需要搜索ID这棵B+树；
如果语句是select * from T where k=5，即普通索引查询方式，则需要先搜索k索引树，得到ID的值为500，再到ID索引树搜索一次。这个过程称为回表。
????????也就是说，基于非主键索引的查询需要多扫描一棵索引树。因此，我们在应用中应该尽量使用主键查询。
总结
到此这篇关于mysql数据库之索引详细介绍的文章就介绍到这了,更多相关mysql索引内容请搜索
标签：SQL
相关阅读 >>
数据库sqlparameter 的插入操作,防止sql注入的实现代码
sqlserver 2000数据库同步 同步两个sqlserver数据库的内容
更多相关阅读请进入《sql》频道 >>
数据库系统概念 第6版
本书主要讲述了数据模型、基于对象的数据库和XML、数据存储和查询、事务管理、体系结构等方面的内容。
感谢您的支持，我会继续努力的!
打开支付宝扫一扫，即可进行扫码打赏哦
分享从这里开始，精彩与您同在
相关推荐
评论
管理员已关闭评论功能...