一條SQL語句執行得很慢的原因有哪些

2021-09-27 10:06:02 字數 4388 閱讀 1951

1. 大多數情況是正常的,只是偶爾會出現很慢的情況。

2. 在資料量不變的情況下,這條sql語句一直以來都執行的很慢。

一條 sql 大多數情況正常,偶爾才能出現很慢的情況,針對這種情況,我覺得這條sql語句的書寫本身是沒什麼問題的,而是其他原因導致的,那會是什麼原因呢?

資料庫在重新整理髒頁(flush)我也無奈啊

當我們要往資料庫插入一條資料、或者要更新一條資料的時候,我們知道資料庫會在記憶體中把對應欄位的資料更新了,但是更新之後,這些更新的字段並不會馬上同步持久化到磁碟中去,而是把這些更新的記錄寫入到 redo log 日記中去,等到空閒的時候,在通過 redo log 裡的日記把最新的資料同步到磁碟中去。

當記憶體資料頁跟磁碟資料頁內容不一致的時候,我們稱這個記憶體頁為「髒頁」。記憶體資料寫入到磁碟後,記憶體和磁碟上的資料頁的內容就一致了,稱為「乾淨頁」。

刷髒頁有下面4種場景(後兩種不用太關注「效能」問題):

拿不到鎖我能怎麼辦

這個就比較容易想到了,我們要執行的這條語句,剛好這條語句涉及到的表,別人在用,並且加鎖了,我們拿不到鎖,只能慢慢等待別人釋放鎖了。或者,表沒有加鎖,但要使用到的某個一行被加鎖了,這個時候,我也沒辦法啊。

如果要判斷是否真的在等待鎖,我們可以用 show processlist這個命令來檢視當前的狀態哦,這裡我要提醒一下,有些命令最好記錄一下,反正,我被問了好幾個命令,都不知道怎麼寫,呵呵。

如果在資料量一樣大的情況下,這條 sql 語句每次都執行的這麼慢,那就就要好好考慮下你的 sql 書寫了,下面我們來分析下哪些原因會導致我們的 sql 語句執行的很不理想。

我們先來假設我們有乙個表,表裡有下面兩個字段,分別是主鍵 id,和兩個普通字段 c 和 d。

mysql> create table `t` (

`id` int(11) not null,

`c` int(11) default null,

`d` int(11) default null,

primary key (`id`)

) engine=innodb;

1、扎心了,沒用到索引

沒有用上索引,我覺得這個原因是很多人都能想到的,例如你要查詢這條語句

select * from t where 100 (1)、字段沒有索引

剛好你的 c 欄位上沒有索引,那麼抱歉,只能走全表掃瞄了,你就體驗不會索引帶來的樂趣了,所以,這回導致這條查詢語句很慢。

(2)、欄位有索引,但卻沒有用索引

好吧,這個時候你給 c 這個字段加上了索引,然後又查詢了一條語句

select * from t where c - 1 = 1000;

我想問大家乙個問題,這樣子在查詢的時候會用索引查詢嗎?

答是不會,如果我們在字段的左邊做了運算,那麼很抱歉,在查詢的時候,就不會用上索引了,所以呢,大家要注意這種欄位上有索引,但由於自己的疏忽,導致系統沒有使用索引的情況了。

正確的查詢應該如下

select * from t where c = 1000 + 1;
有人可能會說,右邊有運算就能用上索引?難道資料庫就不會自動幫我們優化一下,自動把 c - 1=1000 自動轉換為 c = 1000+1。

不好意思,確實不會幫你,所以,你要注意了。

3)、函式操作導致沒有用上索引

如果我們在查詢的時候,對欄位進行了函式操作,也是會導致沒有用上索引的,例如

select * from t where pow(c,2) = 1000;
這裡我只是做乙個例子,假設函式 pow 是求 c 的 n 次方,實際上可能並沒有 pow(c,2)這個函式。其實這個和上面在左邊做運算也是很類似的。

所以呢,一條語句執行都很慢的時候,可能是該語句沒有用上索引了,不過具體是啥原因導致沒有用上索引的呢,你就要會分析了,我上面列舉的三個原因,應該是出現的比較多的吧。

2、呵呵,資料庫自己選錯索引了

我們在進行查詢操作的時候,例如

select * from t where 100 < c and c < 100000;
我們知道,主鍵索引和非主鍵索引是有區別的,主鍵索引存放的值是整行字段的資料,而非主鍵索引上存放的值不是整行字段的資料,而且存放主鍵欄位的值。

也就是說,我們如果走 c 這個欄位的索引的話,最後會查詢到對應主鍵的值,然後,再根據主鍵的值走主鍵索引,查詢到整行資料返回。

好吧扯了這麼多,其實我就是想告訴你,就算你在 c 欄位上有索引,系統也並不一定會走 c 這個欄位上的索引,而是有可能會直接掃瞄掃瞄全表,找出所有符合 100 < c and c < 100000 的資料。

為什麼會這樣呢?

其實是這樣的,系統在執行這條語句的時候,會進行**:究竟是走 c 索引掃瞄的行數少,還是直接掃瞄全表掃瞄的行數少呢?顯然,掃瞄行數越少當然越好了,因為掃瞄行數越少,意味著i/o操作的次數越少。

如果是掃瞄全表的話,那麼掃瞄的次數就是這個表的總行數了,假設為 n;而如果走索引 c 的話,我們通過索引 c 找到主鍵之後,還得再通過主鍵索引來找我們整行的資料,也就是說,需要走兩次索引。而且,我們也不知道符合 100 c < and c < 10000 這個條件的資料有多少行,萬一這個表是全部資料都符合呢?這個時候意味著,走 c 索引不僅掃瞄的行數是 n,同時還得每行資料走兩次索引。

所以呢,系統是有可能走全表掃瞄而不走索引的。那系統是怎麼判斷呢?

判斷**於系統的**,也就是說,如果要走 c 字段索引的話,系統會**走 c 字段索引大概需要掃瞄多少行。如果**到要掃瞄的行數很多,它可能就不走索引而直接掃瞄全表了。

那麼問題來了,系統是怎麼**判斷的呢?這裡我給你講下系統是怎麼判斷的吧,雖然這個時候我已經寫到脖子有點酸了。

系統是通過索引的區分度來判斷的,乙個索引上不同的值越多,意味著出現相同數值的索引越少,意味著索引的區分度越高。我們也把區分度稱之為基數,即區分度越高,基數越大。所以呢,基數越大,意味著符合 100 < c and c < 10000 這個條件的行數越少。

所以呢,乙個索引的基數越大,意味著走索引查詢越有優勢。

那麼問題來了,怎麼知道這個索引的基數呢?

系統當然是不會遍歷全部來獲得乙個索引的基數的,代價太大了,索引系統是通過遍歷部分資料,也就是通過取樣的方式,來**索引的基數的。

扯了這麼多,重點的來了,居然是取樣,那就有可能出現失誤的情況,也就是說,c 這個索引的基數實際上是很大的,但是取樣的時候,卻很不幸,把這個索引的基數**成很小。例如你取樣的那一部分資料剛好基數很小,然後就誤以為索引的基數很小。然後就呵呵,系統就不走 c 索引了,直接走全部掃瞄了。

所以呢,說了這麼多,得出結論:由於統計的失誤,導致系統沒有走索引,而是走了全表掃瞄,而這,也是導致我們 sql 語句執行的很慢的原因。

這裡我宣告一下,系統判斷是否走索引,掃瞄行數的**其實只是原因之一,這條查詢語句是否需要使用使用臨時表、是否需要排序等也是會影響系統的選擇的。

不過呢,我們有時候也可以通過強制走索引的方式來查詢,例如

select * from t force index(a) where c < 100 and c < 100000;
我們也可以通過

show index from t;
來查詢索引的基數和實際是否符合,如果和實際很不符合的話,我們可以重新來統計索引的基數,可以用這條命令

analyze table t;
來重新統計分析。

既然會**錯索引的基數,這也意味著,當我們的查詢語句有多個索引的時候,系統有可能也會選錯索引哦,這也可能是 sql 執行的很慢的乙個原因。

好吧,就先扯這麼多了,你到時候能扯出這麼多,我覺得已經很棒了,下面做乙個總結。

1、 大多數情況下很正常,偶爾很慢,則有如下原因

(1)、資料庫在重新整理髒頁,例如 redo log 寫滿了需要同步到磁碟。

(2)、執行的時候,遇到鎖,如表鎖、行鎖。

2、這條 sql 語句一直執行的很慢,則有如下原因。

(1)、沒有用上索引:例如該欄位沒有索引;由於對欄位進行運算、函式操作導致無法用索引。

(2)、資料庫選錯了索引。

一條SQL語句執行得很慢的原因有哪些

一條 sql 語句執行的很慢,那是每次執行都很慢呢?還是大多數情況下是正常的,偶爾出現很慢呢?所以我覺得,我們還得分以下兩種情況來討論。1 大多數情況是正常的,只是偶爾會出現很慢的情況。2 在資料量不變的情況下,這條sql語句一直以來都執行的很慢。針對這兩種情況,我們來分析下可能是哪些原因導致的。一...

一條SQL語句執行得很慢的原因有哪些?

一條 sql 語句執行的很慢,那是每次執行都很慢呢?還是大多數情況下是正常的,偶爾出現很慢呢?所以我覺得,我們還得分以下兩種情況來討論。1 大多數情況是正常的,只是偶爾會出現很慢的情況。2 在資料量不變的情況下,這條sql語句一直以來都執行的很慢。針對這兩種情況,我們來分析下可能是哪些原因導致的。一...

一條SQL語句執行得很慢的原因有哪些?

這個問題可以涉及到 mysql 的很多核心知識,我們從兩個方面進行詳解。1 大多數情況是正常的,只是偶爾會出現很慢的情況。2 在資料量不變的情況下,這條sql語句一直以來都執行的很慢。針對這種情況,這條sql的書寫本身可能是沒有什麼問題的,而是其它原因導致的 當我們要往資料庫插入一條資料 或者要更新...