因?yàn)榫帉懥艘粋€(gè)Python程序，密集的操作了一個(gè)Mysql庫，之前數(shù)據(jù)量不大時(shí)，沒發(fā)現(xiàn)很慢，后來越來越慢，以為只是數(shù)據(jù)量大了的原因，但是后來慢到不能忍受了，查了半天，索引能用的都用上了，執(zhí)行一次還是要3到4秒，不能忍受了。
于是把一些可以緩存的查詢?nèi)坑胷edis緩存了起來，大大加速了應(yīng)用。
但是還是有一些沒辦法緩存的，或者說，每次查詢都是不一樣的結(jié)果的就沒辦法了。用navicat的查詢概況可以看到卡住的地方是在：Sending data一段，用時(shí)3.5秒，占了99%的查詢時(shí)間。
在網(wǎng)上查了一些，有些是因?yàn)閟ql語句的問題，但是我這個(gè)完全沒有用到varchar，也沒用到in方法。
于是想是不是表太大了，可能沒有緩存到內(nèi)存中，于是先查mysqld進(jìn)程占的內(nèi)存，才50多M，明顯太少了，那張表的實(shí)際容量有200多M,這個(gè)可以在navicat的對(duì)象一欄看到，應(yīng)該是每次查都是從磁盤讀取，所以很耗費(fèi)時(shí)間，于是查看win10的磁盤IO,發(fā)現(xiàn)確實(shí)是這樣，磁盤IO達(dá)到了100%，還是固態(tài)硬盤，每秒讀取80M左右，難怪這么慢了。
于是查了mysql的配置文件，發(fā)現(xiàn)有一項(xiàng)配置才32M,調(diào)成512M,重啟mysql，搞定這次從3.5秒變成了0.76秒了。
配置項(xiàng)是：
innodb_buffer_pool_size=32M
這是mysql5.7默認(rèn)的，改成512或1024，再重啟即可，看你的硬件配置。
總結(jié)
以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，謝謝大家對(duì)腳本之家的支持。如果你想了解更多相關(guān)內(nèi)容請(qǐng)查看下面相關(guān)鏈接
您可能感興趣的文章:- MySQL Like模糊查詢速度太慢如何解決
- MySQL開啟慢查詢方法及實(shí)例
- MySQL5.7慢查詢?nèi)罩緯r(shí)間與系統(tǒng)時(shí)間差8小時(shí)原因詳解
- mysql慢查詢操作實(shí)例分析【開啟、測試、確認(rèn)等】
- MySQL 查詢速度慢與性能差的原因與解決方法
- mysql查詢慢的原因和解決方案
- Mysql慢查詢優(yōu)化方法及優(yōu)化原則
- MySQL開啟慢查詢?nèi)罩竟δ艿姆椒?/li>
- MySQL慢查詢?nèi)罩镜幕臼褂媒坛?/li>
- Mysql sql慢查詢監(jiān)控腳本代碼實(shí)例
