索引是什么

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

總結

以上是生活随笔為你收集整理的mysql索引_MySQL索引介绍和实战的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。