一次sql优化的过程--拆解sql

早上接到产品反馈，用户反应系统中有一个常用列表刷新太慢。

找到列表刷新的log位置。

less xxx.log

通过"/"搜索定位到列表刷新的sql。
发现这个sql在只有几千条数据的情况下执行了5s左右。确实有问题。

通过查看该sql的执行计划，定位慢的原因。
explain select * from a left join b on a.id=b.uid where a.age=1;(这个只是一个例子，真实的sql当然比这个复杂)
id  select_type table  type  possible_keys  key   key_len    ref   rows    Extra
1    SIMPLE        a       ALL        null        null   null     null    4578    Using filesort

对于explain这里我就不详细说了，不了解的可以看看之前文章

https://blog.csdn.net/wobuaizhi/article/details/82350328

还有一些定位的方法

https://blog.csdn.net/wobuaizhi/article/details/78785571

今天这个问题时业务要求导致sql必须这样写。

想到的第一个就是把现有的影响性能的部分“移出来 ”，另起一个查询。

拆解后，虽然需要查询两次，但是整体查询时间快了很多。可以满足用户的需求。

 

有时候不能光把眼光放在sql上，结合业务优化可以事半功倍。

 

知识使我快乐