記一次mysql優(yōu)化操作

最近發(fā)現(xiàn)項(xiàng)目的一些操作速度特別慢,原本以為是數(shù)據(jù)量太大造成,后來仔細(xì)分析下來有了重大發(fā)現(xiàn)。
一個很普通的操作,就幾個查詢幾個簡單的修改操作,操作時間盡達(dá)到了30多秒,這個速度是沒法接受的,我們看下分析思路:

1. 查看當(dāng)前的慢查詢:

image.png

結(jié)論

發(fā)現(xiàn)這個簡單的update修改操作盡然在等待了,而且更怪異的是使用了id這種一般建表時的自增唯一主鍵

2. 使用explain大神進(jìn)行分析

image.png

結(jié)論

可以看出id沒有走索引,而是進(jìn)行了全表查詢

發(fā)現(xiàn)了問題,怎么解決呢?

去看表結(jié)構(gòu),發(fā)現(xiàn)表里的 Primary keyUnique 都沒有打?qū)矗ㄏ旅娴慕貓D是我修改后的)

image.png

看下修改后的explain結(jié)果

image.png

可以看出 where 已經(jīng)使用id 索引了,這樣的效率一下就上來了

隨后又對經(jīng)常用到的查詢建立了索引

總之對mysql優(yōu)化的一個目標(biāo)就是盡量想辦法減少查詢掃描表的行數(shù)(即explain結(jié)果里的row字段的值)

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容