關於MySQL索引的深入解析
前言
我們知道,索引的選擇是優化器階段的工作,但是優化器並不是萬能的,它有可能選錯所要使用的索引。一般優化器選擇索引考慮的因素有:掃描行數,是否排序,是否使用臨時表。
使用explain分析sql
explain是很好的自測命令,勤於使用explain有助於我們寫出更合理的sql語句以及建立更合理的索引:
mysql> explain select * from t where (a between 1 and 1000) and (b between 50000 and 100000) order by b limit 1; +----+-------------+-------+------------+-------+---------------+------+---------+------+-------+----------+------------------------------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+-------+------------+-------+---------------+------+---------+------+-------+----------+------------------------------------+ | 1 | SIMPLE | t | NULL | range | a,b | b | 5 | NULL | 50223 | 1.00 | Using index condition; Using where | +----+-------------+-------+------------+-------+---------------+------+---------+------+-------+----------+------------------------------------+ 1 row in set,1 warning (0.01 sec)
其中:
table欄位:表示關於哪張表;
type欄位:system,const,eq_reg,ref,range,index,all。一般來說要達到range級別以上;
system、const:可以將查詢的變數轉為常量,如id=1;id為主鍵或唯一鍵;
eq_ref:訪問索引,返回某單一行的資料,通常在連線時出現,查詢使用的索引為主鍵或唯一鍵;
ref:訪問索引,返回某個值得資料(可能是多行),通常使用=時發生;
range:使用索引返回一個範圍內的行資訊,如使用>,<,between
index:以索引的順序進行全表掃描,雖然有索引不用排序,但是要全表掃描;
all:全表掃描
key欄位:實際使用的索引;
key_len欄位:使用的索引長度(在不損失精度的情況下,長度越短越好);
ref欄位:顯示索引的哪一列被使用了;
rows欄位:MySQL認為檢索需要的資料行數;
Extra欄位:查詢的額外資訊,主要有以下幾種:
using index:使用了索引
using where:使用了where條件
using tmporary:用到臨時表去處理當前查詢
using filesort:用到額外的排序,如order欄位無索引
range checked for eache record(index map:N):無索引可用
using index for group-by:表名可以在索引中找到分組所需的所有資料,不需要查詢實際的表
一般遇到Using temporary和Using filesort就要想辦法優化一下了,因為用不到索引。
MySQL怎麼計算需要檢索的行數
實際中,MySQL所統計的掃描行數並不是精確值,有時候甚至會相差很遠,而掃描行數則是基於索引的基數來計算的。
在MySQL中,通過取樣統計的方式去獲取索引基數:系統預設選取 N 個數據頁,統計資料頁上不同值得平均值,然後乘以索引的頁面數得到基數,而且MySQL會在變更的資料行數超過 1/M 時來觸發重做索引統計的操作。
在MySQL中,有2種儲存索引統計的方式,可以通過設定innodb_stats_persistent引數來選擇:
設定為 on 的時候,表示統計資訊會持久化儲存。這時,預設的 N 是 20,M 是 10。
設定為 off 的時候,表示統計資訊只儲存在記憶體中。這時,預設的 N 是 8,M 是 16。
一般來說,基數統計出來的資料和真實的行數沒有很大差距,但是涉及到刪除資料新增資料比較頻繁的資料表,可能會出現資料表有10萬條資料但是基數統計卻有20萬的情況,這就可能是MVCC在作怪了,因為MySQL的InnoDB的事務支援,需要維持多個數據版本,就有可能某些事務還沒結束,還在使用刪除了很久的資料導致已刪除的資料空間無法釋放,而新增的資料又開闢了新的空間,那麼這時候就導致基數統計中資料頁數量可能出現失誤,出現較大誤差。
一個很好的修正方式就是執行analyze table 表名,該命令用來重新統計索引資訊。
索引選錯了我們到底怎麼辦
當我們正確的建立必須的索引後,大部分情況下,優化器其實並不會選擇錯索引,當我們遇到索引選錯的情況下,該怎麼去處理呢?
1、使用force index強制使用某個索引。
2、轉換思路,優化一下sql語句可能就會使用到該使用的索引。
3、新建更合適的索引或刪除掉誤用到的不合理的索引。(有些時候,可能真的是這個索引是多餘的,還不是最優的,優化器又剛好使用到了它)。
總結
以上就是這篇文章的全部內容了,希望本文的內容對大家的學習或者工作具有一定的參考學習價值,謝謝大家對我們的支援。