mysql索引创建及使用注意事项
總結：
1、在使用索引時，一般情況下不建議使用like操作。如果使用，則%放在后面。否則不會使用索引。like ‘%abd%’不會使用索引,而like ‘aaa%’可以使用索引.（最左綴原則）
2、單列索引的使用：
《1》 只涉及到其中一個字段時，都能使用到索引
《2》模糊查詢時，%如果在前面，那么不會使用索引
《3》涉及到多個索引字段時，如果這些索引字段中，存在主鍵索引，那么只會使用該索引
《4》涉及到多個索引字段時,如果這些索引字段中，不存在主鍵索引的話，那么就會使用該使用的索引（注：如果通過其中的部分索引就能準確定位的話，那么其余的索引就不再被使用）
《5》當對索引字段進行?>，?<，>=，?<=，not in，between …… and ……，函數(索引字段，substr)，like模糊查詢%在字段前時，不會使用該索引
總結mysql索引失效的N種情況 https://www.jianshu.com/p/3ccca0444432
3、組合索引的使用：
最左原則：
???????假設組合索引為：a,b,c的話;那么當SQL中對應有：a或a，b或a，b，c的時候，可稱為完全滿足最左原則；當SQL中對應只有a，c的時候，可稱為部分滿足最左原則；當SQL中沒有a的時候，可稱為不滿足最左原則。
注：SQL語句中的對應條件的先后順序無關。
《1》當完全滿足最左原則時，所有字段都會使用組合索引
《2》當部分滿足最左原則時，只有a字段會使用組合索引（a,c 中只有a會使用組合索引）
《3》當不滿足最左原則時，不使用組合索引
《4》滿足(部分滿足)最左原則的字段里，有字段不滿足“索引”自身的使用規范：
? ? ? ? ? ?說明：如果SQL語句里的字段里，滿足了最左原則，但是不滿足“索引”自身的使用規范，那么組合索引走到這里之后，
? ? ? ? ? ?不會再往下走了
索引的創建：
建表時創建：
CREATE TABLE 表名(
字段名 數據類型 [完整性約束條件],
???????……，
[UNIQUE | FULLTEXT | SPATIAL] INDEX | KEY
[索引名](字段名1 [(長度)] [ASC | DESC]) [USING 索引方法]
);
說明：
- UNIQUE:可選。表示索引為唯一性索引。
- FULLTEXT:可選。表示索引為全文索引。
- SPATIAL:可選。表示索引為空間索引。
- INDEX和KEY:用于指定字段為索引，兩者選擇其中之一就可以了，作用是 ???一樣的。
- 索引名:可選。給創建的索引取一個新名稱。
- 字段名1:指定索引對應的字段的名稱，該字段必須是前面定義好的字段。
- 長度:可選。指索引的長度，必須是字符串類型才可以使用。
- ASC:可選。表示升序排列。
- DESC:可選。表示降序排列。
注：索引方法默認使用BTREE。
單列索引(示例)：
CREATE TABLE projectfile (id INT AUTO_INCREMENT COMMENT '附件id',fileuploadercode VARCHAR(128) COMMENT '附件上傳者code',projectid INT COMMENT '項目id;此列受project表中的id列約束',filename VARCHAR (512) COMMENT '附件名',fileurl VARCHAR (512) COMMENT '附件下載地址',filesize BIGINT COMMENT '附件大小，單位Byte',-- 主鍵本身也是一種索引（注:也可以在上面的創建字段時使該字段主鍵自增）PRIMARY KEY (id),-- 主外鍵約束（注:project表中的id字段約束了此表中的projectid字段）FOREIGN KEY (projectid) REFERENCES project (id),-- 給projectid字段創建了唯一索引(注:也可以在上面的創建字段時使用unique來創建唯一索引)UNIQUE INDEX (projectid),-- 給fileuploadercode字段創建普通索引INDEX (fileuploadercode)-- 指定使用INNODB存儲引擎(該引擎支持事務)、utf8字符編碼 ) ENGINE = INNODB DEFAULT CHARSET = utf8 COMMENT '項目附件表';注：這里只為示例如何創建索引，其他的合理性之類的先放一邊。
組合索引(示例)：
CREATE TABLE projectfile (id INT AUTO_INCREMENT COMMENT '附件id',fileuploadercode VARCHAR(128) COMMENT '附件上傳者code',projectid INT COMMENT '項目id;此列受project表中的id列約束',filename VARCHAR (512) COMMENT '附件名',fileurl VARCHAR (512) COMMENT '附件下載地址',filesize BIGINT COMMENT '附件大小，單位Byte',-- 主鍵本身也是一種索引（注:也可以在上面的創建字段時使該字段主鍵自增）PRIMARY KEY (id),-- 創建組合索引INDEX (fileuploadercode,projectid)-- 指定使用INNODB存儲引擎(該引擎支持事務)、utf8字符編碼 ) ENGINE = INNODB DEFAULT CHARSET = utf8 COMMENT '項目附件表';
建表后創建：
ALTER?TABLE?表名?ADD?[UNIQUE | FULLTEXT | SPATIAL]??INDEX | KEY??[索引名]?(字段名1 [(長度)] [ASC | DESC])?[USING 索引方法]；
或
CREATE??[UNIQUE | FULLTEXT | SPATIAL]??INDEX??索引名?ON??表名(字段名)?[USING 索引方法]
示例一：
-- 假設建表時fileuploadercode字段沒創建索引(注:同一個字段可以創建多個索引，但一般情況下意義不大) -- 給projectfile表中的fileuploadercode創建索引 ALTER TABLE projectfile ADD UNIQUE INDEX (fileuploadercode);
示例二：
示例三：
查看已創建的索引：
show index from 表名；
提示:我們也可以直接使用工具查看
示例：
索引的刪除：
DROP INDEX 索引名 ON 表名
或
ALTER TABLE 表名 DROP INDEX?索引名
示例一：
drop index fileuploadercode1 on projectfile;
示例二：
查看SQL語句對索引的使用情況(即:查詢SQL的查詢執行計劃QEP)：
在select語句前加上EXPLAIN即可。
示例：
EXPLAIN SELECT * FROM `index_demo` ii WHERE ii.e_name = 'Jane';
分析該SQL的性能為：
提示：我們也可以使用SQL工具查看，如：navicat中的“解釋”選項即可查看。
說明：
id：SELECT識別符。這是SELECT的查詢序列號。
select_type：SELECT類型。
table：表名
type：聯接類型。是SQL性能的非常重要的一個指標，結果值從好到壞依次是：system > const > eq_ref > ref
????????????> fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL。
????????????一般來說，得保證查詢至少達到range級別。
possible_keys：possible_keys列指出MySQL能使用哪個索引在該表中找到行。注意，該列完全獨立于EXPLAIN輸出所示的表的次序。這意味著在possible_keys中的某些鍵實際上不能按生成的表次序使用。
key：key列顯示MySQL實際決定使用的鍵(索引)。如果沒有選擇索引，鍵是NULL。要想強制MySQL使用或忽視possible_keys列中的索引，在查詢中使用FORCE INDEX、USE INDEX或者IGNORE INDEX。
key_len：key_len列顯示MySQL決定使用的鍵長度。如果鍵是NULL，則長度為NULL。注意通過key_len值我們可以確定MySQL將實際使用一個多部關鍵字的幾個部分。
ref：ref列顯示使用哪個列或常數與key一起從表中選擇行。
rows：rows列顯示MySQL認為它執行查詢時必須檢查的行數。
Extra：該列包含MySQL解決查詢的詳細信息。
單列索引的使用：
準備工作：
給id加主鍵索引：
再分別給name、city、country、address加上普通索引：
注：以上五個索引都是單列索引。
使用情況：
只涉及到其中的一個字段時，都能使用到索引(以e_name為例):
注：模糊查詢時，%如果在前面，那么不會使用索引。
涉及到多個索引字段時,如果這些索引字段中，存在主鍵索引，那么只會使用該索引（即:MYSQL優化器會選出并先執行最“嚴”的索引）:
提示：possible_key中，只是SQL語句里涉及到的索引；key中才是實際上執行查詢操作時使用到了的索引。
涉及到多個索引字段時,如果這些索引字段中，不存在主鍵索引的話，那么就會使用該使用的索引（注：如果通過其中的部分索引就能準確定位的話，那么其余的索引就不再被使用）:
注：多個索引時，先使用哪個索引后使用哪個索引，是由MySQL的優化器經過一些列計算后作出的抉擇。
當對索引字段進行?>，?<，>=， <=，not in，between …… and ……，函數(索引字段)，like模糊查詢%在字段前時，不會使用該索引
注：這里對e_age字段進行了 “<” ，所以實際查詢時，并沒有使用e_age的索引。
提示：在實際使用時，如果涉及到多列，我們一般都不會將這些列一 一創建為單列索引，而是將這些列創建為組合索引。
組合索引的使用：
最左原則：
???????假設組合索引為：a,b,c的話;那么當SQL中對應有：a或a，b或a，b，c的時候，可稱為完全滿足最左原則；當SQL中對應只有a，c的時候，可稱為部分滿足最左原則；當SQL中沒有a的時候，可稱為不滿足最左原則。
創建了組合索引:e_name，e_age，e_country，e_city。
使用情況：
完全滿足最左原則：
注：與條件的先后無關，即：下面這樣的話，也是會完整的走組合索引的：
部分滿足最左原則：
注：此SQL中，只有e_name和e_country滿足部分最左原則(e_name滿足)，所以到e_name字段時會走組合所以，但是
? ? ? ?只會走到e_name那里，到e_country時就不會使用組合索引了。
不滿足最左原則：
滿足(部分滿足)最左原則的字段里，有字段不滿足“索引”自身的使用規范：
說明：如果SQL語句里的字段里，滿足了最左原則，但是不滿足“索引”自身的使用規范，那么組合索引走到這里之后，
? ? ? ? ? ?不會再往下走了。
如圖所示：由于e_age字段使用了“>”符號，不符合“索引”自身的使用規范，那么當“e_name”走完組合索引后，
? ? ? ? ? ? ? ? ??走到“e_age”時，該字段及其后面的字段不會再走組合索引了。
^_^ 如有不當之處，歡迎指正
^_^ 參考鏈接
????????https://www.cnblogs.com/DreamDrive/p/7752960.html、?
????????https://www.cnblogs.com/tommy-huang/p/4317305.html、
????????https://blog.csdn.net/linjpg/article/details/56054994、
????????https://www.jb51.net/article/118371.html
^_^ 如涉及侵權問題，請及時聯系我
^_^ 本文已經被收錄進《程序員成長筆記(二)》，筆者JustryDeng
?————————————————?
版權聲明：本文為CSDN博主「justry_deng」的原創文章，遵循CC 4.0 by-sa版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/justry_deng/article/details/81458470
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
? ? ? ??
總結
以上是生活随笔為你收集整理的mysql索引创建及使用注意事项的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 数据结构-栈5-栈的应用-后缀转中缀
- 下一篇： rt-thread怎么使用数码管_三菱F