早上接到產品反饋，用戶反應系統中有一個常用列表刷新太慢。
找到列表刷新的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上，結合業務優化可以事半功倍。
知識使我快樂