MySQL效能和索引優化,order by,explain優化
今天我們來講講如何優化MySQL的效能,主要從索引方面優化。下期文章講講MySQL慢查詢日誌
,我們是依據慢查詢日誌來判斷哪條SQL語句有問題,然後在進行優化,敬請期待MySQL慢查詢日誌篇
建表
//建表
CREATETABLEIFNOTEXISTSstaffs(
idINTPRIMARYKEYAUTO_INCREMENT,
nameVARCHAR(24)NOTNULLDEFAULT""COMMENT'姓名',
ageINTNOTNULLDEFAULT0COMMENT'年齡',
posVARCHAR(20)NOTNULLDEFAULT""COMMENT'職位',
add_timeTIMESTAMPNOTNULLDEFAULTCURRENT_TIMESTAMPCOMMENT'入職事件'
)CHARSETutf8COMMENT'員工記錄表';
//插入資料
INSERTINTO`test`.`staffs`(`name`,`age`,`pos`,`add_time`)VALUES('z3',22,'manager',now());
INSERTINTO`test`.`staffs`(`name`,`age`,`pos`,`add_time`)VALUES('July',23,'dev',now());
INSERTINTO`test`.`staffs`(`name`,`age`,`pos`,`add_time`)VALUES('2000',23,'dev',now());
//建立複合索引(即一個索引包含多個欄位)
ALTERTABLEstaffsADDINDEXidx_staffs_nameAgePos(name,age,pos);
複製程式碼
優化一:全部用到索引
介紹
建立的複合索引包含了幾個欄位,查詢的時候最好能全部用到,而且嚴格按照索引順序,這樣查詢效率是最高的。(最理想情況,具體情況具體分析)
SQL 案例
優化二:最左字首法則
介紹
如果建立的是複合索引,索引的順序要按照建立時的順序,即從左到右,如:a->b->c(和 B+樹的資料結構有關)
無效索引舉例
- a->c:a 有效,c 無效
- b->c:b、c 都無效
- c:c 無效
SQL 案例
優化三:不要對索引做以下處理
以下用法會導致索引失效
- 計算,如:+、-、*、/、!=、<>、is null、is not null、or
- 函式,如:sum()、round()等等
- 手動/自動型別轉換,如:id = "1",本來是數字,給寫成字串了
SQL 案例
優化四:索引不要放在範圍查詢右邊
舉例
比如複合索引:a->b->c,當 where a="" and b>10 and 3="",這時候只能用到 a 和 b,c 用不到索引,因為在範圍之後索引都失效(和 B+樹結構有關)
SQL 案例
優化五:減少 select * 的使用
使用覆蓋索引
即:select 查詢欄位和 where 中使用的索引欄位一致。
SQL 案例
優化六:like 模糊搜尋
失效情況
- like "%張三%"
- like "%張三"
解決方案
- 使用複合索引,即 like 欄位是 select 的查詢欄位,如:select name from table where name like "%張三%"
- 使用 like "張三%"
SQL 案例
優化七:order by 優化
當查詢語句中使用 order by 進行排序時,如果沒有使用索引進行排序,會出現 filesort 檔案內排序,這種情況在資料量大或者併發高的時候,會有效能問題,需要優化。
filesort 出現的情況舉例
- order by 欄位不是索引欄位
- order by 欄位是索引欄位,但是 select 中沒有使用覆蓋索引,如:
select * from staffs order by age asc;
- order by 中同時存在 ASC 升序排序和 DESC 降序排序,如:
select a, b from staffs order by a desc, b asc;
- order by 多個欄位排序時,不是按照索引順序進行 order by,即不是按照最左字首法則,如:
select a, b from staffs order by b asc, a asc;
索引層面解決方法
- 使用主鍵索引排序
- 按照最左字首法則,並且使用覆蓋索引排序,多個欄位排序時,保持排序方向一致
- 在 SQL 語句中強制指定使用某索引,force index(索引名字)
- 不在資料庫中排序,在程式碼層面排序
order by 排序演算法
- 雙路排序
Mysql4.1 之前是使用雙路排序,字面的意思就是兩次掃描磁碟,最終得到資料,讀取行指標和 ORDER BY 列,對他們進行排序,然後掃描已經排好序的列表,按照列表中的值重新從列表中讀取對資料輸出。也就是從磁碟讀取排序欄位,在 buffer 進行排序,再從磁碟讀取其他欄位。
檔案的磁碟 IO 非常耗時的,所以在 Mysql4.1 之後,出現了第二種演算法,就是單路排序。
- 單路排序
從磁碟讀取查詢需要的所有列,按照 orderby 列在 buffer 對它們進行排序,然後掃描排序後的列表進行輸出, 它的效率更快一些,避免了第二次讀取資料,並且把隨機 IO 變成順序 IO,但是它會使用更多的空間, 因為它把每一行都儲存在記憶體中了。
當我們無可避免要使用排序時,索引層面沒法在優化的時候又該怎麼辦呢?儘可能讓 MySQL 選擇使用第二種單路演算法來進行排序。這樣可以減少大量的隨機 IO 操作,很大幅度地提高排序工作的效率。下面看看單路排序優化需要注意的點
單路排序優化點
-
增大 max_length_for_sort_data
在 MySQL 中,決定使用"雙路排序"演算法還是"單路排序"演算法是通過引數 maxlength_forsort_data 來決定的。當所有返回欄位的最大長度小於這個引數值時,MySQL 就會選擇"單路排序"演算法,反之,則選擇"多路排序"演算法。所以,如果有充足的記憶體讓 MySQL 存放須要返回的非排序欄位,就可以加大這個引數的值來讓 MySQL 選擇使用"單路排序"演算法。
-
去掉不必要的返回欄位,避免select *
當記憶體不是很充裕時,不能簡單地通過強行加大上面的引數來強迫 MySQL 去使用"單路排序"演算法,否則可能會造成 MySQL 不得不將資料分成很多段,然後進行排序,這樣可能會得不償失。此時就須要去掉不必要的返回欄位,讓返回結果長度適應 max_length_for_sort_data 引數的限制。
-
增大 sort_buffer_size 引數設定
這個值如果過小的話,再加上你一次返回的條數過多,那麼很可能就會分很多次進行排序,然後最後將每次的排序結果再串聯起來,這樣就會更慢,增大 sort_buffer_size 並不是為了讓 MySQL 選擇"單路排序"演算法,而是為了讓 MySQL 儘量減少在排序過程中對須要排序的資料進行分段,因為分段會造成 MySQL 不得不使用臨時表來進行交換排序。
但是sort_buffer_size 不是越大越好:
- Sort_Buffer_Size 是一個 connection 級引數,在每個 connection 第一次需要使用這個 buffer 的時候,一次性分配設定的記憶體。
- Sort_Buffer_Size 並不是越大越好,由於是 connection 級的引數,過大的設定和高併發可能會耗盡系統記憶體資源。
- 據說 Sort_Buffer_Size 超過 2M 的時候,就會使用 mmap() 而不是 malloc() 來進行記憶體分配,導致效率降低。
優化八:group by
其原理也是先排序後分組,其優化方式可參考order by。where高於having,能寫在where限定的條件就不要去having限定了。