mysql資料庫的sql執行計畫詳解

2021-12-30 09:56:27 字數 2533 閱讀 3960

引言:

實際專案開發中,由於我們不知道實際查詢的時候資料庫裡發生了什麼事情,資料庫軟體是怎樣掃瞄表、怎樣使用索引的,因此,我們能感知到的就只有

sql 語句執行的時間,在資料規模不大時,查詢是瞬間的,因此,在寫 sql 語句的時候就很少考慮到效能的問題。但是當資料規模增大,如千萬、億的時候,我們運

行同樣的 sql 語句時卻發現遲遲沒有結果,這個時候才知道資料規模已經限制了我們查詢的速度。所以,查詢優化和索引也就顯得很重要了。

問題:當我們在查詢前能否預先估計查詢究竟要涉及多少行、使用哪些索引、執行時間呢?答案是能的,mysql 提供了相應的功能和語法來實現該功能。

分析:mysql 提供了 explain 語法用來進行查詢分析,在 sql 語句前加乙個「explain」即可。比如我們要分析如下 sql 語句:

explain select * from table where table.id = 1

執行上面的 sql 語句後你會看到,下面的表頭資訊:

table | type | possiblekeys | key | keylen | ref | rows | extra

explain 列的解釋

table

顯示這一行的資料是關於哪張表的

type

這是重要的列,顯示連線使用了何種型別。從最好到最差的連線型別為 const、eq_reg、ref、range、indexhe 和 all

說明:不同連線型別的解釋(按照效率高低的順序排序)

system:表只有一行:system 表。這是 const 連線型別的特殊情況。

const :表中的乙個記錄的最大值能夠匹配這個查詢(索引可以是主鍵或惟一索引)。因為只有一行,這個值實際就是常數,因為 mysql 先讀這個值然後把它當做常數來對待。

eq_ref:在連線中,mysql 在查詢時,從前面的表中,對每乙個記錄的聯合都從表中讀取乙個記錄,它在查詢使用了索引為主鍵或惟一鍵的全部時使用。

ref:這個連線型別只有在查詢使用了不是惟一或主鍵的鍵或者是這些型別的部分(比如,利用最左邊字首)時發生。對於之前的表的每乙個行聯合,全部記錄都將從表中讀出。這個型別嚴重依賴於根據索引匹配的記錄多少—越少越好。

range:這個連線型別使用索引返回乙個範圍中的行,比如使或查詢東西時發生的情況。

index:這個連線型別對前面的表中的每乙個記錄聯合進行完全掃瞄(比 all 更好,因為索引一般小於表資料)。

all:這個連線型別對於前面的每乙個記錄聯合進行完全掃瞄,這一般比較糟糕,應該盡量避免。

possible_keys

顯示可能應用在這張表中的索引。如果為空,沒有可能的索引。可以為相關的域從 where 語句中選擇乙個合適的語句

key實際使用的索引。如果為 null,則沒有使用索引。很少的情況下,mysql 會選擇優化不足的索引。這種情況下,可以在 select 語句中使用 use index(indexname)來強制使用乙個索引或者用 ignore index(indexname)來強制 mysql 忽略索引

key_len

使用的索引的長度。在不損失精確性的情況下,長度越短越好

ref顯示索引的哪一列被使用了,如果可能的話,是乙個常數

rows

mysql 認為必須檢查的用來返回請求資料的行數

extra

關於 mysql 如何解析查詢的額外資訊。將在表 4.3 中討論,但這裡可以看到的壞的例子是 using temporary 和 using filesort,意思 mysql 根本不能使用索引,結果是檢索會很慢

說明:extra 列返回的描述的意義

distinct :一旦 mysql 找到了與行相聯合匹配的行,就不再搜尋了。

not exists :mysql 優化了 left join,一旦它找到了匹配 left join 標準的行,就不再搜尋了。

range checked for each record(index map:#) :沒有找到理想的索引,因此對從前面表中來的每乙個行組合,mysql 檢查使用哪個索引,並用它來從表中返回行。這是使用索引的最慢的連線之一。

using filesort :看到這個的時候,查詢就需要優化了。mysql 需要進行額外的步驟來發現如何對返回的行排序。它根據連線型別以及儲存排序鍵值和匹配條件的全部行的行指標來排序全部行。

using index :列資料是從僅僅使用了索引中的資訊而沒有讀取實際的行動的表返回的,這發生在對錶的全部的請求列都是同乙個索引的部分的時候。

using temporary :看到這個的時候,查詢需要優化了。這裡,mysql 需要建立乙個臨時表來儲存結果,這通常發生在對不同的列集進行 order by 上,而不是 group by 上。

因此,弄明白了 explain 語法返回的每一項結果,我們就能知道查詢大致的執行時間了,如果查詢裡沒有用到索引、或者需要掃瞄的行過多,那麼可以感到明顯的延遲。因此需要改變查詢方式或者新建索引。mysql 中的 explain 語法可以幫助我們改寫查詢,優化表的結構和索引的設定,從而最大地提高查詢效率。當然,在大規模資料量時,索引的建立和維護的代價也是很高的,往往需要較長的時間和較大的空間,如果在不同的列組合上建立索引,空間的開銷會更大。因此索引最好設定在需要經常查詢的字段中。

資料庫監測sql執行

sql server profiler可以檢測在資料上執行的語句,特別是有的專案不直接使用sql語句,直接使用orm框架的系統處理資料庫的專案,在除錯sql語句時,給了很大的幫助。之前寫了使用sql server profiler追蹤死鎖的文章 sql server profiler追蹤資料庫死鎖 ...

資料庫監測sql執行

sql server profiler可以檢測在資料上執行的語句,特別是有的專案不直接使用sql語句,直接使用orm框架的系統處理資料庫的專案,在除錯sql語句時,給了很大的幫助。之前寫了使用sql server profiler追蹤死鎖的文章 sql server profiler追蹤資料庫死鎖 ...

解析MySQL資料庫中執行SQL語句的注意點

在執行查詢命令時的大小寫問題 預設情況下,mysql在執行查詢時不區分字母的大小寫。當你在查詢時使用like a 時,預設將返回以a或者a開頭的所有列值,若要在查詢時區分大小寫,則需要使用collate運算子來實現,具體例子如下 如果想讓某列在查詢時始終保持區分字母大小寫,則需要用case sens...