鍍金池/ 問答/數(shù)據(jù)庫/ 關(guān)于mysql優(yōu)化問題

關(guān)于mysql優(yōu)化問題

explain SELECT m.*,u.username nickname,u.vip,u.appid FROM wwj_mingxi m left join wwj_user u on u.id=m.uid  WHERE u.appid = 0 ORDER BY id desc LIMIT 0,20

clipboard.png
索引也建了，但是查詢還是要4s.還有方法優(yōu)化嗎

回答
編輯回答
純妹

left join換成join
appid加個(gè)索引

2017年10月3日 02:27
編輯回答
荒城

using temporary,using filesort ---表示用了臨時(shí)表和文件排序，當(dāng)然會(huì)慢了。

為什么會(huì)產(chǎn)生臨時(shí)表和文件排序? 我猜是因?yàn)?你用m作為主表，又用了u.id作為排序，解決方法是：

  1. 如果你用u.id來排序，那最好用u來作主表去join m表
  2. 如果不能改用u作主表，那可以試試將主表改為子查詢，將排序放到子查詢中
2017年9月13日 17:21
編輯回答
痞性

從你的explain中能看出。一共檢索 91585 行。4秒肯定索引建立不正確。 起到作用的索引 u.appid，m.user_id_ix。你應(yīng)該 u.id ,m.uid 建立相應(yīng)的索引或外鍵。

2017年8月14日 16:52
編輯回答
命多硬

你那是明細(xì)表和用戶表join吧。

  1. where條件里有u.appid=0，那說明肯定是可以用right join代替你的left join，right join會(huì)更快一些；
  2. u.id,m.uid,u.appid要是都有索引就更快了，你最后的order by id其實(shí)就是order by u.id吧，order by 的字段最好也是要索引的。
2018年1月11日 12:02
編輯回答
嫑吢丕

出現(xiàn)了using temporary，這里mysql需要?jiǎng)?chuàng)建一個(gè)臨時(shí)表來存儲(chǔ)結(jié)果，這通常發(fā)生在對(duì)不同的列集進(jìn)行order by。

2018年5月9日 06:37