这篇文章将为大家详细讲解有关InnoDB主键索引树和免费云主机域名二级索引树的示例分析，小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。我们这里讨论InnoDB存储引擎，数据和索引存储在同一个文件student.ibduid是主键，其他字段没有添加任何索引如果是这样查询，这表示整表搜索，从左到右遍历叶子节点链表，从小到大访问如果是这样查询，这表示范围查询，就直接在有序链表中遍历搜索就可以了，直到遍历到第一个不小于5的key结束遍历如果是这样查询，这表示等值查询，在索引树上进行二分查找即可由于name没有索引，于是做整表搜索uid是主键，以name创建了普通索引（二级索引）以name为索引构建的索引树，称为辅助索引树，也叫做二级索引树。key是辅助索引字段name的值，然后还有外加uid主键的值在辅助索引树上，key是辅助索引的值，也就是name；data数据值是所在记录行的主键值（PRIMARY KEY），也就是uid（并不是表的一行数据）分析语句1：因为过滤字段是name且 只select了name一个字段，name有索引，索引树上直接就有，所以从name的二级索引树上去等值匹配linfeng分析语句2：这种情况select的是name和uid，而这些在二级索引树上也是直接就有，所以搜索二级索引树就完事了。分析语句3：这种情况下就涉及到回表了，这是一个很重要的概念。由于name字段有索引，所以我们会到name字段构建的二级索引树上去查找。但二级索引树没有linfeng这个人所有的信息，所以完整的查询过程应该是这样的：用linfeng到二级索引树上进行匹配，拿到二级索引树上存储的uid然后拿着这个uid去主索引树上去匹配，最后拿到linfeng的所有信息（回表）
而这个回表意味着更多的磁盘I/O，会影响效率，如果业务只需要uid、name，就别写select *了，这样可以避免回表分析语句4：我们删除name的索引后执行以下语句没有用到索引，还使用外部排序了。此外我们还看到using filesort，这时需要优化了。我们的过滤条件是age，先给age添加索引，看看行不行可以看到，age命中索引了，查询age所在的索引树。由于我们写的是select *，依然存在回表。还有using filesort，因为使用age=20查询到的结果是多个，然而name此时是没有顺序的，所以还需要再进行外部排序。那能不能通过给name加载索引来解决问题呢？不能，因为一次SQL执行只能用到1个索引，搜索了这个字段的索引树就不会再去搜索另一个字段的索引树了，因为加载索引是要耗费磁盘I/O的，查找多个索引树就太慢了！分析：既然索引树上只能存自己建立的索引字段以及主键，那我们把需要查询的字段都设置成索引不就好了？解决方法：我们可以在二级索引树上的key：age+name，形成联合索引，先按age排序，age相同了，再按name排序再次select *这时候就使用到联合索引了，而且没有using filesort，这次是这样查询的：先用age=20在辅助索引树上查找，如果数据足够会找到多个结果，这个结果就是已经排好序的，不需要再using filesort我们现在直接用第二个字段name作为过滤条件我们看到这里没有用到索引，因为我们用(age,name)创建索引，是先按age排序，再按name排序。如果我们只用name作为过滤条件，这就没有办法使用索引匹配了，因为是优先用age排序。所以我们经常说，多列索引一定要使用到第1个字段，这样才能用到索引！在建立(age,name)联合索引的情况下，以下操作不回表（到二级索引树上搜索，再去主索引树上搜索）：select ageselect age, nameselect uid,age,name以下操作要回表select *select age,name,sex关于“InnoDB主键索引树和二级索引树的示例分析”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。
本篇内容主要讲解“MINA框架的视图层和逻辑层实例分析”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“MINA框架的视图层和逻辑层实例分析”吧! 1. 开篇导言 目标用户：无编程经验，但对微信小程序感兴趣的同学。学习…
免责声明：本站发布的图片视频文字，以转载和分享为主，文章观点不代表本站立场，本站不承担相关法律责任；如果涉及侵权请联系邮箱：360163164@qq.com举报，并提供相关证据，经查实将立刻删除涉嫌侵权内容。
微信扫一扫 
