MySQL性能優化，MySQL索引優化，order by優化，explain優化

前言

今天咱們來說講如何優化MySQL的性能，主要從索引方面優化。下期文章講講MySQL慢查詢日誌，咱們是依據慢查詢日誌來判斷哪條SQL語句有問題，而後在進行優化，敬請期待MySQL慢查詢日誌篇

建表

// 建表
CREATE TABLE IF NOT EXISTS staffs(
    id INT PRIMARY KEY AUTO_INCREMENT,
    name VARCHAR(24) NOT NULL DEFAULT "" COMMENT'姓名',
    age INT NOT NULL DEFAULT 0 COMMENT'年齡',
    pos VARCHAR(20) NOT NULL DEFAULT "" COMMENT'職位',
    add_time TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT'入職事件'
) CHARSET utf8 COMMENT'員工記錄表';
// 插入數據
INSERT INTO `test`.`staffs` (`name`, `age`, `pos`, `add_time`) VALUES ('z3', 22, 'manager', now());
INSERT INTO `test`.`staffs` (`name`, `age`, `pos`, `add_time`) VALUES ('July', 23, 'dev', now());
INSERT INTO `test`.`staffs` (`name`, `age`, `pos`, `add_time`) VALUES ('2000', 23, 'dev', now());
// 創建複合索引（即一個索引包含多個字段）
ALTER TABLE staffs ADD INDEX idx_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 中,決定使用"雙路排序"算法仍是"單路排序"算法是經過參數 max_length_for_ sort_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限定了。

IT 老哥

一個經過自學，進入大廠作高級Java開發的程序猿，但願能經過個人分享，讓你學到知識