這篇文章主要講解了“MySQL索引的優(yōu)缺點是什么”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“MySQL索引的優(yōu)缺點是什么”吧！
成都創(chuàng)新互聯(lián)服務項目包括高青網(wǎng)站建設、高青網(wǎng)站制作、高青網(wǎng)頁制作以及高青網(wǎng)絡營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關系等，向廣大中小型企業(yè)、政府機構等提供互聯(lián)網(wǎng)行業(yè)的解決方案，高青網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前，我們服務的客戶以成都為中心已經(jīng)輻射到高青省份的部分城市，未來相信會繼續(xù)擴大服務區(qū)域并繼續(xù)獲得客戶的支持與信任！
在 SQL 優(yōu)化中，索引是至關重要的一環(huán)，能給查詢效率帶來質的飛躍，但是索引并不是萬能的，不合理的索引設計甚至會拖慢查詢效率。
索引是一種專門用于幫助 SQL 高效獲取數(shù)據(jù)的數(shù)據(jù)結構，一個常用的例子是，索引類似于一本書的目錄，可以快速對特定值進行定位和查找，從而大大加快數(shù)據(jù)查詢的效率。實際上，索引也是一張表，這張表保存了主鍵與索引字段，并指向實體表的記錄（類似指針）。
索引大大減小了服務器需要掃描的數(shù)據(jù)量
索引可以幫助服務器避免排序和臨時表
索引可以將隨機IO變成順序IO
索引對于InnoDB（對索引支持行級鎖）非常重要，InnoDB僅對需要訪問的元組加鎖，而索引能夠減少InnoDB訪問的元組數(shù)。如果查詢不能使用索引，MySQL會進行全表掃描，并鎖住每一個元組，不管是否真正需要。
雖然索引大大提高了查詢速度，同時卻會降低更新表的速度。因為更新表時，MySQL不僅要保存數(shù)據(jù)，還要保存索引文件。因此，對應更新非常頻繁的字段，通常不建議使用索引。
建立索引會占用磁盤空間。
如果某個數(shù)據(jù)列包含許多重復的內容，為它建立索引效果就很差，這個性質稱為索引的選擇性：不重復的索引值和數(shù)據(jù)表中的記錄總數(shù)的比值。索引的選擇性越高則查詢效率越高。比如對性別字段建立索引，一百萬條數(shù)據(jù)，只有男女兩種可能，索引選擇性為五十萬分之一，索引效果就很差
對于非常小的表，索引意義不大，大部分情況下簡單的全表掃描更高效。
因此應該只為最經(jīng)常查詢和最經(jīng)常排序的數(shù)據(jù)列建立索引。MySQL里同一個數(shù)據(jù)表里的索引總數(shù)限制為16個。
從功能邏輯來劃分，索引主要分為 普通索引、唯一索引、主鍵索引和全文索引
最基本的索引，它沒有任何限制。普通索引（由關鍵字KEY或INDEX定義的索引）的唯一任務是加快對數(shù)據(jù)的訪問速度。因此，應該只為那些最經(jīng)常出現(xiàn)在查詢條件(WHERE column = …)或排序條件(ORDER BY column)中的數(shù)據(jù)列創(chuàng)建索引。
普通索引的創(chuàng)建有三種方式。
# 創(chuàng)建索引CREATE INDEX idx_username ON user_tbl(username);# 對于字符串字段，可以手動指定長度，如 user_tbl(username(5))，表示只用前五個字符來做索引，可以進一步加快查詢效率，索引長度要小于字段長度# 修改表結構ALTER TABLE user_tbl ADD INDEX idx_username (username)# 創(chuàng)建表的時候直接指定，如CREATE TABLE user_tbl( ID INT NOT NULL, username VARCHAR(16) NOT NULL, INDEX idx_username (username) );
刪除索引
DROP INDEX idx_username ON user_tbl;
查看索引
SHOW INDEX FROM user_tbl;
它與前面的普通索引類似，不同的就是：普通索引允許被索引的數(shù)據(jù)列包含重復的值。而唯一索引列的值必須唯一，但允許有空值。如果是組合索引，則列值的組合必須唯一。
唯一索引的創(chuàng)建跟普通索引類似：
#創(chuàng)建索引 CREATE UNIQUE INDEX idx_username ON user_tbl(username); # 修改表結構 ALTER TABLE user_tbl ADD UNIQUE idx_username (username) # 創(chuàng)建表的時候直接指定 CREATE TABLE user_tbl( ID INT NOT NULL, username VARCHAR(16) NOT NULL, UNIQUE idx_username (username) );
它是一種特殊的唯一索引，不允許有空值。一張表只能有一個主鍵，一般是在建表的時候同時創(chuàng)建。
CREATE TABLE user_tbl( ID INT NOT NULL, username VARCHAR(16) NOT NULL, PRIMARY KEY(ID) );
與之類似的是外鍵索引，如果為某個外鍵字段定義了一個外鍵約束條件，MySQL就會定義一個內部索引來幫助自己以最有效率的方式去管理和使用外鍵約束條件。
在上一篇文章 MySQL 基礎語法 中，我們說過如果使用了 LIKE + % 開頭，就索引會失效，那么當我們需要前后都模糊搜索的需求（如 LIKE ‘%hello%’），就需要使用全文索引，需要注意的是，Innodb 只有在 5.6 版本之后才支持全文索引。
全文索引的創(chuàng)建和刪除：
# 創(chuàng)建的兩種方法 CREATE FULLTEXT INDEX idx_name ON tbl_name(field_name); ALTER TABLE tbl_name ADD FULLTEXT INDEX idx_name(field_name); # 刪除的兩種方法 DROP INDEX idx_name ON tbl_name; ALTER TABLE tbl_name DROP INDEX idx_name;
使用全文索引進行全模糊匹配的語法為：
重慶分公司
重慶分公司
SELECT XXX FROM tbl_name WHERE match(field_name) against('xxx');
# 比如對 user_tbl 的 user_name 字段加了全文索引
# 查詢結果等效于 SELECT user_name, user_id FROM user_tbl WHERE user_name LIKE '%hello%';
SELECT user_name, user_id FROM user_tbl WHERE match(user_name) against('hello');使用 explain 檢查，可以發(fā)現(xiàn) fulltext 索引生效。
按物理實現(xiàn)方式來劃分，通?？梢苑譃榫奂饕头蔷奂饕?。
存儲內容是按照聚集索引排序的，聚集索引的順序和行記錄的順序一致,一張表只能有一個聚集索引。聚集索引的葉子節(jié)點直接儲存聚集索引指向的內容，因此查詢的時候只需要進行一次查找。
聚集索引在創(chuàng)建主鍵時自動生成，如果沒有主鍵，則根據(jù)第一個不為空的唯一索引自動生成，如果還沒有，則自動生成一個隱式的聚集索引。
需要注意的是，在進行查詢操作的時候，聚集索引的效率更高，因為少了一次查找；但是進行修改操作的時候，效率比非聚集索引低，因為直接修改了數(shù)據(jù)內容，為了標準數(shù)據(jù)內容的順序和聚集索引順序一致，會對數(shù)據(jù)頁重新排序。
非聚集索引雖然索引項是順序存儲的，但是索引項對應的內容是隨機存儲的，系統(tǒng)會維護單獨的索引表來存儲索引。
非聚集索引的葉子節(jié)點存儲的是數(shù)據(jù)的地址，查詢非聚集索引的時候，系統(tǒng)會進行兩次查找，先查找索引，再查找索引對應位置的數(shù)據(jù)。因此非聚集索引也叫二級索引或者輔助索引。
按字段個數(shù)可以把索引分為單一索引和聯(lián)合索引。
索引字段只有一列時為單一索引，上述所有索引都是單一索引。
將多個字段組合在一起創(chuàng)建的索引叫聯(lián)合索引。如下：
ALTER TABLE user_tbl ADD INDEX idx_name_city_age (username,city,age);
建立這樣的聯(lián)合索引，其實是相當于分別建立了下面三組聯(lián)合索引：
usernname,city,age usernname,city usernname
為什么沒有 city，age 這樣的聯(lián)合索引呢？這是因為MySQL聯(lián)合索引的最左匹配原則，只會按照最左優(yōu)先的順序進行索引匹配，也就是說，(x,y,z) 和 (z,y,x) 是不同的索引，即使是使用聯(lián)合索引中的字段查詢，聯(lián)合索引也有可能失效。
對于 (x,y,z)，只有在以下查詢條件聯(lián)合索引會生效：
WHERE x = 1WHERE x = 1 AND y = 1WHERE x = 1 AND y = 1 AND z = 1
對于其他情況，比如 WHERE y = 1 、WHERE y = 1 AND z = 1 等，就不會匹配聯(lián)合索引，索引失效，注意對于 WHERE x = 1 AND z = 1，聯(lián)合索引會對 x 生效，但是對 z 不生效。
可以擴展了解一下，理論上最左匹配原則中索引對 where 中子句的順序也是敏感的，但是由于MySQL的查詢優(yōu)化器會自動調整 where 子句的條件順序以使用適合的索引，所以實際上 where 子句順序不影響索引的效果。
要注意的是，如果聯(lián)合索引查詢過程中有范圍查詢，就會停止匹配，比如下面的語句中， z 字段不能使用到索引：
WHERE x = 1 AND y > 2 AND z = 3
順便提一下，可以用 explain 命令來查看在某個查詢語句中索引是否生效，具體用法請參考官網(wǎng)文檔。
如果分別在 x, y, z 上建立單列索引，讓該表有3個單列索引，索引效率也會大不一樣，在聯(lián)合索引生效的情況下，單個索引的效率遠遠低于聯(lián)合索引。這是由 MySQL 查詢優(yōu)化器的執(zhí)行順序決定的，在執(zhí)行一條查詢 sql 時，針對索引的選擇大致有如下步驟：
MySQL 優(yōu)化器根據(jù)搜索條件，找出所有可能使用的索引
計算全表掃描的代價
計算使用不同索引執(zhí)行查詢的代價
對比各種執(zhí)行方案的代價，找出成本最低的那一個
因此，雖然有多個單列索引，但 MySQL 只能用到其中的那個系統(tǒng)認為似乎是最有效率的，其他的就會失效。
不同的 mysql 數(shù)據(jù)引擎支持不同結構的索引，按結構劃分，常用的索引為 B+樹索引、Hash 索引、FULLTEXT索引 等，將在下一篇文章 MySQL 索引結構 中介紹。
接下來我們來簡單總結一下在什么場景下推薦使用索引。
WHERE, GROUP BY, ORDER BY 子句中的字段
多個單列索引在多條件查詢是只會有一個最優(yōu)的索引生效，因此多條件查詢中最好創(chuàng)建聯(lián)合索引。
聯(lián)合索引的時候必須滿足最左匹配原則，并且最好考慮到 sql 語句的執(zhí)行順序，比如 WHERE a = 1 GROUP BY b ORDER BY c, 那么聯(lián)合索引應該設計為 (a,b,c)，因為在上一篇文章 MySQL 基礎語法 中我們介紹過，mysql 查詢語句的執(zhí)行順序 WHERE > GROUP BY > ORDER BY。
多張表 JOIN 的時候，對表連接字段創(chuàng)建索引。
當 SELECT 中有不在索引中的字段時，會先通過索引查詢出滿足條件的主鍵值，然后通過主鍵回表查詢出所有的 SELECT 中的字段，影響查詢效率。因此如果 SELECT 中的內容很少，為了避免回表，可以把 SELECT 中的字段都加到聯(lián)合索引中，這也就是寬索引的概念。但是需要注意，如果索引字段過多，存儲和維護索引的成本也會增加。
數(shù)據(jù)量很小的表
有大量重復數(shù)據(jù)的字段
頻繁更新的字段
如果對索引字段使用了函數(shù)或者表達式計算，索引失效
innodb OR 條件沒有對所有條件創(chuàng)建索引，索引失效
大于小于條件 < >，索引是否生效取決于命中的數(shù)量比例，如果命中數(shù)量很多，索引生效，命中數(shù)量很小，索引失效
不等于條件 != <>，索引失效
LIKE 值以 % 開頭，索引失效
感謝各位的閱讀，以上就是“MySQL索引的優(yōu)缺點是什么”的內容了，經(jīng)過本文的學習后，相信大家對MySQL索引的優(yōu)缺點是什么這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關知識點的文章，歡迎關注！
