MySQL索引介紹和實戰

索引是什么

MySQL官方對索引的定義為：索引(Index)是幫助MySQL高效獲取數據的數據結構。

可以得到索引的本質：索引是數據結構，索引的目的是提高查詢效率，可以類比英語新華字典，根據目錄定位詞語

如果沒有目錄呢，就需要從A到Z，去遍歷的查找一遍，一個一個找和直接根據目錄定位到數據，差的就是天壤之別

 

索引底層數據結構

數據庫除了存儲數據本身之外，還維護着一個滿足特定查找算法的數據結構，這些結構以某種方式指向數據，這樣就可以基於這些數據結構實現高效查找算法。這種結構就是索引,MySQL中索引是B+樹實現的,每個索引都對應一棵B+樹

 

索引的優勢

• 提高數據檢索效率，降低數據庫IO成本

• 通過索引列對數據進行排序，降低數據排序成本，降低了CPU消耗

索引的劣勢

• 一個索引都為對應一棵B+樹，樹中每一個節點都是一個數據頁，一個頁默認會占用16KB的存儲空間，所以一個索引也是會占用磁盤空間的。(空間的代價)

• 索引是對數據的排序，當對表中的數據進行增、刪、改操作時，都要維護修改內容涉及到的B+樹索引。所以在進行這些操作時需要額外的時間進行一些記錄移動，頁面分裂、頁面回收等操作來維護索引(時間上的代價)

索引語法

以test_user表為例,建表sql如下

CREATE TABLE `test_user` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主鍵id',
  `user_id` varchar(36) NOT NULL COMMENT '用戶id',
  `user_name` varchar(30) NOT NULL COMMENT '用戶名稱',
  `phone` varchar(20) NOT NULL COMMENT '手機號碼',
  `lan_id` int(9) NOT NULL COMMENT '本地網',
  `region_id` int(9) NOT NULL COMMENT '區域',
  `create_time` datetime NOT NULL COMMENT '創建時間',
  PRIMARY KEY (`id`),
  KEY `idx_user_id` (`user_id`)
) ENGINE=InnoDB AUTO_INCREMENT=1010001 DEFAULT CHARSET=utf8mb4;

 

 1.查看索引：SHOW INDEX FROM table_name\G

SHOW INDEX FROM test_user;

 

 

2.刪除索引：DROP INDEX [indexName] ON mytable;

DROP INDEX idx_user_id ON test_user;

 

 

3.創建索引 alter tableName add [unique] index [indexName] on (columnName (length) )

ALTER TABLE test_user ADD INDEX idx_user_id(user_id);

 

 

哪些情況需要建索引

• 主鍵自動建立唯一索引
• 頻繁作為查詢的條件的字段應該創建索引
• 查詢中與其他表關聯的字段，外鍵關系建立索引
• 頻繁更新的字段不適合創建索引：因為每次更新不單單是更新了記錄還會更新索引，加重IO負擔
• Where條件里用不到的字段不創建索引
• 單間/組合索引的選擇問題（在高並發下傾向創建組合索引）
• 查詢中排序的字段，若通過索引去訪問將大大提高排序的速度
• 查詢中統計或者分組字段

哪些不適合建索引

• 表記錄太少

• 經常增刪改的表

• 數據重復且分布平均的表字段，如果某個數據列包含許多重復的內容，為它建立索引就沒有太大的實際效果。

 

索引實戰

我們在test_user表中有100萬數據

 

 

優化一：使用全部索引

1.不加索引,關閉緩存查一條數據

SELECT SQL_NO_CACHE * FROM `test_user` WHERE phone='15190427892' AND lan_id=317 AND region_id=92

 

2.加一條復合索引

ALTER TABLE test_user ADD INDEX idx_phone_lan_region(phone,lan_id,region_id);

再查一次,看結果

 

 可以看到,加了索引以后,查詢效率提高了很多

這里我們建立的復合索引包含的3個字段，查詢的時候全部用到了，而且where中的條件嚴格按照索引順序，這樣查詢效率是最高的

我們使用EXPLAIN關鍵字看一下

 

優化二：最左前綴法則

我們把上面那個例子的第一個插件條件刪掉

EXPLAIN SELECT SQL_NO_CACHE * FROM `test_user` WHERE  lan_id=317 AND region_id=92;

我們使用EXPLAIN關鍵字看一下

 

 因此,我們得出結論:如果建立的是復合索引，索引的順序要按照建立時的順序，即從左到右，如：a->b->c（和 B+樹的數據結構有關）

無效索引舉例

• a->c：a 有效，c 無效
• b->c：b、c 都無效
• c：c 無效

 

優化三：不要對索引做以下處理

• 計算，如：+、-、*、/、!=、<>、is null、is not null、or
• 函數，如：sum()、round()等等
• 手動/自動類型轉換，如：id = "1"，本來是數字，給寫成字符串了

我們以!=為例演示,我們使用EXPLAIN關鍵字看一下

 

 

優化四：索引不要放在范圍查詢右邊

比如復合索引：a->b->c，當 where a="" and b>10 and c=""，這時候只能用到 a 和 b，c 用不到索引，因為在范圍之后索引都失效（和 B+樹結構有關）

如下

EXPLAIN SELECT SQL_NO_CACHE * FROM `test_user` WHERE phone='15190427892' AND lan_id>317 AND region_id=92;

我們使用EXPLAIN關鍵字看一下

 

 我們把最后一個條件刪除,再看一下

 

 

優化五：減少 select * 的使用

select *會查詢很多不必要的字段,造成不必要的網絡傳輸和IO消耗

 

優化六：like 模糊搜索

失效情況

• like "%張三%"
• like "%張三"

 

解決方案

• 使用復合索引，即 like 字段是 select 的查詢字段，如：select name from table where name like "%張三%"
• 使用 like "張三%"

 

 

 

優化七：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;

如下情況沒有索引

 

  filesort 文件內排序會在內存開辟一塊空間,然后把數據復制了一份放到這個空間內,再進行排序,這個是很影響性能的

我們可以為這個字段建一個索引

ALTER TABLE test_user ADD INDEX idx_create_time(create_time);

索引層面解決方法

• 使用主鍵索引排序
• 按照最左前綴法則，並且使用覆蓋索引排序，多個字段排序時，保持排序方向一致
• 在 SQL 語句中強制指定使用某索引，force index(索引名字)
• 不在數據庫中排序，在代碼層面排序

 

優化八：group by

其原理也是先排序后分組，其優化方式可參考order by。where高於having,能寫在where限定的條件就不要去having限定了。