mysql优化：覆盖索引（延迟关联）

我们都知道InnoDB采用的B+ tree来实现索引的，索引又分为主键索引(聚簇索引)和普通索引(二级索引)。

那么我们就来看下 基于主键索引和普通索引的查询有什么区别？

举个栗子：

可以看出我们有一个普通索引k，那么两颗B+树的示意图如下：

[图片上传失败...(image-9b05f7-1597911217600)]

（注：图来自极客时间专栏）

当我们查询** select * from T where k=5 其实会先到k那个索引树上查询k = 5，然后找到对应的id为500，最后回表到主键索引的索引树找返回所需数据。

如果我们查询 select id from T where k=5 **则不需要回表就直接返回。

也就是说，基于非主键索引的查询需要多扫描一棵索引树。因此，我们在应用中应该尽量使用主键查询。

概念如上，这里我们还是用例子来说明：

</pre>

[图片上传失败...(image-20977-1597911217600)]

（注：图来自极客时间专栏）

现在，我们一起来看看这条SQL查询语句的执行流程： select * from T where k between 3 and 5

在这个过程中， 回到主键索引树搜索的过程，我们称为回表。 可以看到，这个查询过程读了k索引树的3条记录（步骤1、3和5），回表了两次（步骤2和4）。

在这个例子中，由于查询结果所需要的数据只在主键索引上有，所以不得不回表。那么，有没有可能经过索引优化，避免回表过程呢？

如果执行的语句是select ID from T where k between 3 and 5，这时只需要查ID的值，而ID的值已经在k索引树上了，因此可以直接提供查询结果，不需要回表。也就是说，在这个查询里面，索引k已经“覆盖了”我们的查询需求，我们称为覆盖索引。

由于覆盖索引可以减少树的搜索次数，显著提升查询性能，所以使用覆盖索引是一个常用的性能优化手段。

需要注意的是，在引擎内部使用覆盖索引在索引k上其实读了三个记录，R3~R5（对应的索引k上的记录项），但是对于MySQL的Server层来说，它就是找引擎拿到了两条记录，因此MySQL认为扫描行数是2。

上面介绍了那么多 其实是在为延迟关联做铺垫，这里直接续上我们本次慢查询的sql：

我们都知道在做分页时会用到Limit关键字去筛选所需数据，limit接受1个或者2个参数，接受两个参数时第一个参数表示偏移量，即从哪一行开始取数据，第二个参数表示要取的行数。 如果只有一个参数，相当于偏移量为0。

当偏移量很大时，如limit 100000,10 取第100001-100010条记录，mysql会取出100010条记录然后将前100000条记录丢弃，这无疑是一种巨大的性能浪费。

当有这种写法时，我们可以采用延迟关联来进行优化，重点关注： SELECT id FROM qa_question WHERE expert_id = 69 AND STATUS = 30 ORDER BY over_time DESC LIMIT 0, 10 ， 这里其实利用了索引覆盖，where条件后的expert_id 是有添加索引的，这里查询id 可以避免回表，大大提升效率。

工作中会遇到各种各样的问题，对于一个研发来说最重要的是能够从这些问题中学到什么。好久没有写博客了，究其原因还是自己变得懒惰了。 (￣ェ￣)

最后以《高性能Mysql》中的一段话结束：

可以通过监控show slave status\G命令输出的Seconds_Behind_Master参数的值来判断，是否有发生主从延时。

其值有这么几种：

NULL - 表示io_thread或是sql_thread有任何一个发生故障，也就是该线程的Running状态是No,而非Yes.

0 - 该值为零，是我们极为渴望看到的情况，表示主从复制良好，可以认为lag不存在。

正值 - 表示主从已经出现延时，数字越大表示从库落后主库越多。

负值 - 几乎很少见，只是听一些资深的DBA说见过，其实，这是一个BUG值，该参数是不支持负值的，也就是不应该出现。

---