早上接到产品反馈,用户反应系统中有一个常用列表刷新太慢。
找到列表刷新的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上,结合业务优化可以事半功倍。
知识使我快乐