因?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秒，不能忍受了。

我們提供的服務(wù)有：網(wǎng)站設(shè)計(jì)制作、成都做網(wǎng)站、微信公眾號(hào)開(kāi)發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認(rèn)證、彝良ssl等。為數(shù)千家企事業(yè)單位解決了網(wǎng)站和推廣的問(wèn)題。提供周到的售前咨詢和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的彝良網(wǎng)站制作公司

于是把一些可以緩存的查詢?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ì)創(chuàng)新互聯(lián)的支持。如果你想了解更多相關(guān)內(nèi)容請(qǐng)查看下面相關(guān)鏈接

分享標(biāo)題：Mysql查詢很慢卡在sendingdata的原因及解決思路講解
路徑分享：http://vcdvsql.cn/article40/jhjeho.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供微信公眾號(hào)、手機(jī)網(wǎng)站建設(shè)、移動(dòng)網(wǎng)站建設(shè)、ChatGPT、網(wǎng)站內(nèi)鏈、用戶體驗(yàn)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)