扫二维码与项目经理沟通
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流
聚集索引:数据行的物理顺序与列值(一般是主键的那一列)的逻辑顺序相同,一个表中只能拥有一个聚集索引。 叶子结点存储索引和行记录,聚簇索引查询会很快,因为可以直接定位到行记录。
创新互联成立于2013年,是专业互联网技术服务公司,拥有项目网站制作、做网站网站策划,项目实施与项目整合能力。我们以让每一个梦想脱颖而出为使命,1280元西乡做网站,已为上家服务,为西乡各地企业和个人服务,联系电话:18982081108
非聚集索引:该索引中索引的逻辑顺序与磁盘上行的物理存储顺序不同,一个表中可以拥有多个非聚集索引。 叶子节点存储聚簇索引值(主键id),需要扫码两遍索引树,先通过普通索引定位到主键值id,再通过聚集索引定位到行记录。
回表查询可以理解为普通索引的查询,先定位主键值,再定位行记录,它的性能较扫一遍索引树更低。
索引覆盖,即将查询sql中的字段添加到联合索引里面,只要保证查询语句里面的字段都在索引文件中,就无需进行回表查询;
实际开发中,不可能把所有字段建立到联合索引,可根据实际业务场景,把经常需要查询的字段建立到联合索引中。
在Mysql5.6的版本上推出,用于优化查询。 在索引遍历过程中,对索引中包含的字段先做判断,直接过滤掉不满足条件的记录,减少回表次数。
优化超多分页场景。 查询条件放到子查询中,子查询只查主键id,然后使用子查询中确定的主键关联查询其他的属性字段。
通过索引查数据其实是分两步:
1、通过索引字段查到数据的主键ID
2、通过主键ID查询全部数据
其中第二步就是索引回表,要避免索引回表,就要保证查询的数据只包含主键和索引字段本身,这样第二步就可以省了
一张用于用户登录的user表:id、userName、Password三个字段
再根据查出来的user信息去对比密码是否正确
这时你发现username字段是唯一的又经常作为where条件所以可以给username字段建一个索引,于是就给username建了一个普通的B+Tree索引。这时候就出问题的,因为MySQL的InnoDB使用聚簇索引,具体的数据只和主键索引放在一起,其他的索引只存储了数据的地址(主键id)。比如上面的例子中,我根据username索引找到的只是一个username为admin这条数据的id而不是这条数据信息,所以要找到整条数据信息要根据得到的id再去找。看完上面的流程,你应该已经发现问题了,我要通过username找到id,再根据id找整条数据,这里有两个查找过程,这是影响效率的。就像上面的两个查找过程就是回表了。
解决办法
使用覆盖索引可以解决上面所说的回表的问题。还是拿上面上面登录的例子来说,其实登录只需要判断用户名和密码,如果user表中有其他用户信息也是不需要的,那我们能不能只查询一次就找到这个用户名对应的密码呢。这个是可以的,上面所说的分两步查找,第一步根据username查找是肯定不能少的,那我们只要把password和索引username放到一起就可以了。我们可以建立一个(username、password)的组合索引,这里username一定要放在前面,然后我们把sql语句改一下
这样建立组合索引后根据username查找password,只要一步查找就可以查找到,因为password已经是username索引的一部分了,直接可以查出来,不再需要通过id找对应的整条数据。覆盖索引就是覆盖了多个列(字段)的索引。
那我们应该如何避免回表,因为如果用到了回表,就需要二次查询的过程,效率肯定更慢,很简单,回表是因为要查询的字段在非聚集索引里没有,所以在满足需求的情况下,我们尽量使非聚集索引里有要查询的索引字段。
在查询时,可以尽量用聚集索引来查(也就是用主键来查询),或者根据业务需求,建好的索引,满足索引查询字段。但是实际业务中,很难建立一个索引就能满足所有查询要求,所以,正常情况,回表也没事,只要能用到索引也能大大加快查询速度。
无论单列索引 or 联合索引,一个索引就对应一个独立的B+索引树,索引树节点仅包含:
即使根据索引树按条件找到所需数据,也仅是索引里的几个字段的值和主键值,万一你搞个select *,那就还得其他字段,就需回表,根据主键到聚簇索引里找,聚簇索引的叶节点是数据页,找到数据页才能把一行数据所有字段值读出来。
所以类似
得从联合索引的索引树里按序取出所有数据,接着对每条数据都走一个主键的聚簇索引查找,性能不高。
有时MySQL执行引擎可能认为,你要是类似
相当于得把联合索引和聚簇索引,两个索引的所有数据都扫描一遍,那还不如不走联合索引,直接全表扫描得了,这样就只需扫描一个主键索引。
但若形如:
那执行引擎就知道你先扫描联合索引的索引树,拿到10条数据,接着对10条数据在聚簇索引里查找10次即可,那就还是会走联合索引。
覆盖索引不是一种索引,只是一种基于索引查询的方式,即针对类似
仅需联合索引里的几个字段的值,那就只需扫描联合索引的索引树,无需回表找其它字段,这种查询方式就是覆盖索引。
所以当你使用联合索引时,注意是否可能会导致大量回表到聚簇索引,若回表聚簇索引的次数太多,可能就直接给你做成全表扫描而不走联合索引了。
尽可能还是在SQL里指定你仅需要的字段,而不要暴力select *,最好直接走覆盖索引。
即使无可避免地要回表,你也尽可能用limit、 where限定一下回表的次数,就从联合索引里筛选少数数据,再回表,这样性能好一点。
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流