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限定了。
&n