Mysql查詢很慢卡在sending data的原因及解決思路講解
因?yàn)榫帉?xiě)了一個(gè)Python程序,密集的操作了一個(gè)Mysql庫(kù),之前數(shù)據(jù)量不大時(shí),沒(méi)發(fā)現(xiàn)很慢,后來(lái)越來(lái)越慢,以為只是數(shù)據(jù)量大了的原因,但是后來(lái)慢到不能忍受了,查了半天,索引能用的都用上了,執(zhí)行一次還是要3到4秒,不能忍受了。
于是把一些可以緩存的查詢?nèi)坑胷edis緩存了起來(lái),大大加速了應(yīng)用。
但是還是有一些沒(méi)辦法緩存的,或者說(shuō),每次查詢都是不一樣的結(jié)果的就沒(méi)辦法了。用navicat的查詢概況可以看到卡住的地方是在:Sending data一段,用時(shí)3.5秒,占了99%的查詢時(shí)間。
在網(wǎng)上查了一些,有些是因?yàn)閟ql語(yǔ)句的問(wèn)題,但是我這個(gè)完全沒(méi)有用到varchar,也沒(méi)用到in方法。
于是想是不是表太大了,可能沒(méi)有緩存到內(nèi)存中,于是先查mysqld進(jìn)程占的內(nèi)存,才50多M,明顯太少了,那張表的實(shí)際容量有200多M,這個(gè)可以在navicat的對(duì)象一欄看到,應(yīng)該是每次查都是從磁盤(pán)讀取,所以很耗費(fèi)時(shí)間,于是查看win10的磁盤(pán)IO,發(fā)現(xiàn)確實(shí)是這樣,磁盤(pán)IO達(dá)到了100%,還是固態(tài)硬盤(pán),每秒讀取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é)
以上就是這篇文章的全部?jī)?nèi)容了,希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,謝謝大家對(duì)腳本之家的支持。如果你想了解更多相關(guān)內(nèi)容請(qǐng)查看下面相關(guān)鏈接
相關(guān)文章
MySQL最大連接數(shù)max_connections設(shè)置的兩種方法
MySQL的最大連接數(shù)可以通過(guò)兩種方法進(jìn)行設(shè)置,通過(guò)命令行臨時(shí)修改和通過(guò)配置文件永久修改這兩種方法,本文將通過(guò)代碼示例給大家詳細(xì)的講解一下這兩種方法,需要的朋友可以參考下2024-05-05
MySQL 5.0.96 for Windows x86 32位綠色精簡(jiǎn)版安裝教程
這篇文章主要介紹了MySQL 5.0.96 for Windows x86 32位綠色精簡(jiǎn)版安裝教程,需要的朋友可以參考下2017-10-10
Mysql5.7.18版本(二進(jìn)制包安裝)自定義安裝路徑教程詳解
這篇文章主要介紹了Mysql5.7.18版本(二進(jìn)制包安裝)自定義安裝路徑教程詳解,需要的朋友可以參考下2017-07-07
MySQL8.0.27安裝過(guò)程中卡在Initializing?Database中并報(bào)錯(cuò)的解決
本文主要介紹了MySQL8.0.27安裝過(guò)程中卡在Initializing?Database中并報(bào)錯(cuò)的解決,文中通過(guò)示例代碼介紹的非常詳細(xì),具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2022-05-05
MySQL與PHP的基礎(chǔ)與應(yīng)用專題之?dāng)?shù)據(jù)查詢
MySQL是一個(gè)關(guān)系型數(shù)據(jù)庫(kù)管理系統(tǒng),由瑞典MySQL?AB?公司開(kāi)發(fā),屬于?Oracle?旗下產(chǎn)品。MySQL?是最流行的關(guān)系型數(shù)據(jù)庫(kù)管理系統(tǒng)之一,本系列將帶你掌握php與mysql的基礎(chǔ)應(yīng)用,本篇從數(shù)據(jù)的查詢開(kāi)始2022-02-02

