一條 SQL?查詢語句執(zhí)行的很慢，那是每次查詢都很慢呢？還是大多數(shù)情況下是正常的，偶爾出現(xiàn)很慢呢？可以分以下兩種情況來討論。

大多數(shù)情況是正常的，只是偶爾會出現(xiàn)很慢的情況。

在數(shù)據(jù)量不變的情況下，這條SQL語句一直以來都執(zhí)行的很慢。

一、平常執(zhí)行快，偶爾很慢

針對這種情況，可以理解為這條SQL語句的書寫本身是沒什么問題的。而是其他原因?qū)е碌?#xff0c;那會是什么原因呢？

(1)? 數(shù)據(jù)庫在刷新臟頁(flush)

要往數(shù)據(jù)庫中插入、更新一條數(shù)據(jù)時，數(shù)據(jù)庫會先在內(nèi)存中將這一條數(shù)據(jù)更新，但卻不會立即持久化到磁盤中，而是把這些記錄寫入到redo log中，等到空閑的時候，再從redo log中把數(shù)據(jù)同步到磁盤中去。

當(dāng)內(nèi)存數(shù)據(jù)頁跟磁盤數(shù)據(jù)頁內(nèi)容不一致的時候，我們稱這個內(nèi)存頁為“臟頁”。內(nèi)存數(shù)據(jù)寫入到磁盤后，內(nèi)存和磁盤上的數(shù)據(jù)頁的內(nèi)容就一致了，稱為“干凈頁”。

redo寫滿了：redo log的容量是有限的，當(dāng)數(shù)據(jù)庫一直很忙，更新又比較頻繁，此時redo log很快被寫滿，數(shù)據(jù)庫就只能先暫停其他操作，全身心將數(shù)據(jù)同步到磁盤中去，所以說，數(shù)據(jù)庫在在同步數(shù)據(jù)到磁盤的時候，就有可能導(dǎo)致我們的SQL語句執(zhí)行的很慢了。

內(nèi)存不夠了：另外，當(dāng)一次性查詢的數(shù)據(jù)太多，又恰好碰到所查詢的數(shù)據(jù)也不在內(nèi)存中，需要申請內(nèi)存，而此時恰好內(nèi)存不足，就需要淘汰一部分內(nèi)存數(shù)據(jù)頁，如果是干凈頁，就直接釋放，如果是臟頁，就需要刷新。

(2)? 拿不到鎖

當(dāng)我們要執(zhí)行的這條語句，它涉及到的表或行，剛好別人在用，且加了鎖，那我們拿不到鎖就只能慢慢等別人釋放鎖了。

如果要判斷是否真的在等待鎖，我們可以用? show processlist? 這個命令來查看當(dāng)前的狀態(tài)。

二、一直都很慢

如果在同一數(shù)據(jù)量的情況下，其他SQL語句執(zhí)行速度都很快，唯獨這條 SQL 語句每次都執(zhí)行的這么慢，那就就要好好反思一下你的 SQL?語句了

(1)? 沒有用到索引

這種情況又要細(xì)分：

a、字段沒有建索引

b、字段有索引，但是沒有用上

比如說select * from table_A a where a.no+1=100? ? ( 就算在no列建立了索引，但是對左邊做了運算，會導(dǎo)致索引失效 )

c、 函數(shù)操作導(dǎo)致索引失效

比如說一個字段name，你對它用了str()或一些其他函數(shù)，也會導(dǎo)致索引失效

(2)? 數(shù)據(jù)庫選錯索引

就算某個字段例如name建立了索引，但系統(tǒng)也會去評估按照索引搜索快還是全表掃描快，而它判斷的依據(jù)是什么呢？采用取樣的方式，來估計數(shù)據(jù)量，所以，如果樣品數(shù)據(jù)不能代表整體數(shù)據(jù)，就會導(dǎo)致偏差，數(shù)據(jù)庫就會誤判。

這種情況下可以強制使用索引，例如 select * from table_A a force index(ind) where 10< a.no and a.no<10000;

三、總結(jié)

一個 SQL 執(zhí)行的很慢，我們要分兩種情況討論：

1、平常執(zhí)行快，偶爾很慢，則有如下原因

a、數(shù)據(jù)庫在刷新臟頁，例如 redo log 寫滿了需要同步到磁盤。

b、執(zhí)行的時候，遇到鎖，如表鎖、行鎖。

2、一直都很慢，則有如下原因。

a、沒有用上索引：例如該字段沒有索引；由于對字段進行運算、函數(shù)操作導(dǎo)致無法用索引。

b、數(shù)據(jù)庫選錯了索引。

總結(jié)

以上是生活随笔為你收集整理的mysql怎么查看刷脏页慢_一条SQL查询语句极为缓慢，如何去优化呢的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。