MySQL性能优化之关联查询优化

上一篇 <<<MySQL性能优化之分页查询优化

下一篇 >>>MySQL性能优化之in、exists优化

推荐阅读：

<<<MySQL执行计划示例解读

<<<MySQL性能优化之慢查询定位

<<<MySQL性能优化之表设计优化

<<<MySQL性能优化之常用SQL语句优化

<<<MySQL性能优化之索引调优实战

<<<MySQL性能优化之分页查询优化

<<<MySQL性能优化之in、exists优化

<<<order by中的单路和双路排序算法原理

<<<MySQL如何性能优化面试题完美解答

t_custom_piont 表数据在 370多万，原有的sql 查询耗时160秒左右，导致微服务之间调用超时

优化后 可以在6秒左右

先对t_custom_goods 等用户领取表先按offer id 分组 count 完当成一个子表，数据减少了很多，再关联查询，降低了查询时间；

我们都知道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》中的一段话结束：

---