10 分鐘 MySQL 索引從入門到精通

10分鐘，只要10分鐘，帶你瞭解 MySQL 索引的精華所在，走一走看一看，看了不吃虧，看了不上當~ :-D

 

一、索引是作什麼的?

索引用於快速找出在某個列中有一特定值的行。不使用索引，MySQL必須從第1條記錄開始而後讀完整個表直到找出相關的行。

表越大，花費的時間越多。若是表中查詢的列有一個索引，MySQL能快速到達一個位置去搜尋到數據文件的中間，沒有必要看全部數據。

大多數MySQL索引(PRIMARY KEY、UNIQUE、INDEX和FULLTEXT)在B樹中存儲。只是空間列類型的索引使用R-樹，而且MEMORY表還支持hash索引。

二、索引好複雜，我該怎麼理解索引，有沒一個更形象點的例子？

有，想象一下，你面前有本詞典，數據就是書的正文內容，你的大腦就是那個cpu，而索引，則是書的目錄

三、索引越多越好？

大多數狀況下索引能大幅度提升查詢效率，但：

• 數據的變動（增刪改）都須要維護索引，所以更多的索引意味着更多的維護成本

• 更多的索引意味着也需要更多的空間 （一本100頁的書，卻有50頁目錄？）

• 太小的表，建索引可能會更慢哦 ：）  （讀個2頁的宣傳手冊，你還先去找目錄？）

四、索引的字段類型問題

• text類型，也可建索引（需指定長度）

• myisam存儲引擎索引鍵長度綜合不能超過1000字節

• 用來篩選的值儘可能保持和索引列一樣的數據類型

五、like 不能用索引？

• 儘可能減小like，但不是絕對不可用，」xxxx%」 是能夠用到索引的，

  想象一下，你在看一本成語詞典，目錄是按成語拼音順序創建，查詢需求是，你想找以 「一」字開頭的成語（」一%「），和你想找包含一字的成語（「%一%」）

• 除了like，如下操做符也可用到索引：

  <，<=，=，>，>=，BETWEEN，IN

  <>，not in ，！=則不行

六、什麼樣的字段不適合建索引？

• 通常來講，列的值惟一性過小（如性別，類型什麼的），不適合建索引（怎樣叫過小？通常說來，同值的數據超過表的百分之15，那就不必建索引了）

• 太長的列，能夠選擇只創建部分索引，（如：只取前十位作索引）

• 更新很是頻繁的數據不適宜建索引（怎樣叫很是？意會）

七、一次查詢能用多個索引嗎?

不能。

好比：

我有一個Ａ表，有ｂ,ｃ,ｄ字段，其中在ｂ,ｃ上各自加了索引。（可使用ＳＱＬ：SHOW INDEX from A 查看Ａ表的索引）

select * from A WHERE b=x and c=x; --x表示要查詢的值

經過這條SQL，咱們能夠看到有兩列：possible_keys和key

pk表示此條ＳＱＬ語句可能用到的索引，ｋ表示實際用到的索引。

你會發現，實際只用到了一個索引，至因而b仍是ｃ，mysql會經過分析選擇使用給出結果集小的索引（cardinality），如經過ｂ索引查詢的記錄比較少, 則會使用b做爲實際索引。

注：嵌套、關聯查詢 explain 下能夠看作屢次查詢，而每次獨立的查詢均可以有單獨的索引被使用。

八、多列查詢該如何建索引?

一次查詢只能用到一個索引，因此 首先槍斃 a，b各建索引方案

a仍是b？ 誰的區分度更高（同值的最少），建誰！

固然，聯合索引也是個不錯的方案，ab，仍是ba，則同上，區分度高者，在前

九、聯合索引的問題?

where a = 「xxx」 可使用 AB 聯合索引

where b = 「xxx」 則不可 （再想象一下，這是書的目錄？）

因此，大多數狀況下，有AB索引了，就能夠不用再去建一個A索引了

十、哪些常見狀況不能用索引?

• like 「%xxx」

• not in ， ！=

• 對列進行函數運算的狀況（如 where md5(password) = 「xxxx」）

• WHERE index=1 OR A=10

• 存了數值的字符串類型字段（如手機號），查詢時記得不要丟掉值的引號，不然沒法用到該字段相關索引，反之則不要緊

  也即

  select * from test where mobile = 13711112222;

  但是沒法用到mobile字段的索引的哦（若是mobile是char 或 varchar類型的話）

  btw，千萬不要嘗試用int來存手機號（爲何？本身想！要不本身試試）

十一、覆蓋索引(Covering Indexes)擁有更高效率

索引包含了所需的所有值的話，就只select 他們，換言之，只select 須要用到的字段，如無必要，儘可能避免select *

十二、NULL 的問題

 

• 要儘可能避免 NULL，儘量地把字段定義爲 NOT NULL。即便應用程序無須保存 NULL（沒有值），也有許多表包含了可空列（Nullable Column）,這僅僅是由於它爲默認選項。除非真的要保存 NULL，不然就把列定義爲 NOT NULL。 

• MySQL難以優化引用了可空列的查詢，它會使索引、索引統計和值更加複雜。可空列須要更多的儲存空間，還須要在MySQL內部進行特殊處理。當可空列被索引的時候，每條記錄都須要一個額外的字節，還可能致使 MyISAM 中固定大小的索引(例如一個整數列上的索引)變成可變大小的索引。 

• 即便要在表中儲存「沒有值」的字段，仍是有可能不使用 NULL 的。考慮使用 0、特殊值或空字符串來代替它。 

• 把 NULL 列改成 NOT NULL 帶來的性能提高很小，因此除非肯定它引入了問題，不然就不要把它看成優先的優化措施。然而，若是計劃對列進行索引，就要儘可能避免把它設置爲可空。 

1三、如何查看索引信息，如何分析是否正確用到索引?

show index from tablename;

explain select ……;

關於explain，改天能夠找個時間專門寫一篇入門帖，在此以前，能夠嘗試 google

1四、瞭解本身的系統，不要過早優化!

過早優化，一直是個很是討厭而又時刻存在的問題，大多數時候就是由於不瞭解本身的系統，不知道本身系統真正的承載能力

好比：幾千條數據的新聞表，天天幾百幾千次的正文搜索，大多數時候咱們能夠放心的去like，而不要又去建一套全文搜索什麼的，畢竟cpu仍是比人腦厲害太多。

1五、後記：

看到這兒，也許你花了不止10分鐘，但建議多看幾遍，有條件的話最好上機嘗試加深理解，紙上得來終覺淺，絕知此事要躬行嘛~

還有這篇文章幾乎覆蓋了《高性能MYSQL》中索引一章的全部結論，建議和那本書參照起來一塊兒看，也許那本書就不那麼難讀了~

Refer：

[1] mysql索引須要瞭解的幾個注意

http://thephper.com/?p=142

[2] mysql 查詢能夠同時使用幾條索引

http://dwz.cn/2cJuCH

[3] MySQL 索引詳解

http://my.oschina.net/leejun2005/blog/134932?fromerr=DQVDBPHK

[4] 關於mysql 索引自動優化機制: 索引選擇性（Cardinality：索引基數）

http://my.oschina.net/leejun2005/blog/75688

[5] 如何應對併發(1) - 關於數據索引

http://dwz.cn/2cJwCQ

[6] 如何應對併發(2) - 請求合併及異步處理

http://dwz.cn/2cJxgS

[7] 如何應對併發(4) - 分佈式數據庫及反範式設計

http://dwz.cn/2dkjJM