前言
MySQL索引的建立對於MySQL的高效執行是很重要的，索引可以大大提高MySQL的檢索速度。
打個比方，如果合理的設計且使用索引的MySQL是一輛蘭博基尼的話，那麼沒有設計和使用索引的MySQL就是一個人力三輪車。
拿漢語字典的目錄頁（索引）打比方，我們可以按拼音、筆畫、偏旁部首等排序的目錄（索引）快速查詢到需要的字。
索引分單列索引和組合索引。單列索引，即一個索引只包含單個列，一個表可以有多個單列索引，但這不是組合索引。組合索引，即一個索引包含多個列。
建立索引時，你需要確保該索引是應用在 SQL 查詢語句的條件(一般作為 WHERE 子句的條件)。
實際上，索引也是一張表，該表儲存了主鍵與索引欄位，並指向實體表的記錄。
上面都在說使用索引的好處，但過多的使用索引將會造成濫用。因此索引也會有它的缺點：雖然索引大大提高了查詢速度，同時卻會降低更新表的速度，如對錶進行INSERT、UPDATE和DELETE。因為更新表時，MySQL不僅要儲存資料，還要儲存一下索引檔案。
建立索引會佔用磁碟空間的索引檔案。
1、索引是做什麼的?
索引用於快速找出在某個列中有一特定值的行。不使用索引，mysql必須從第1條記錄開始然後讀完整個表直到找出相關的行。 表越大，花費的時間越多。如果表中查詢的列有一個索引，mysql能快速到達一個位置去搜尋到資料檔案的中間，沒有必要看所有資料。 大多數mysql索引(PRIMARY KEY、UNIQUE、INDEX和FULLTEXT)在B樹中儲存。只是空間列型別的索引使用R-樹，並且MEMORY表還支援hash索引。
2、索引好複雜，我該怎麼理解索引，有沒一個更形象點的例子？
有，想象一下，你面前有本詞典，資料就是書的正文內容，你就是那個cpu，而索引，則是書的目錄
3、索引越多越好？
大多數情況下索引能大幅度提高查詢效率，但：
資料的變更（增刪改）都需要維護索引，因此更多的索引意味著更多的維護成本
更多的索引意味著也需要更多的空間 （一本100頁的書，卻有50頁目錄？）
過小的表，建索引可能會更慢哦 ：（讀個2頁的宣傳手冊，你還先去找目錄？）
4、索引的欄位型別問題
text型別，也可建索引（需指定長度）
myisam儲存引擎索引鍵長度綜合不能超過1000位元組
用來篩選的值儘量保持和索引列同樣的資料型別
5、like 不能用索引？
儘量減少like，但不是絕對不可用，"xxxx%" 是可以用到索引的，
想象一下，你在看一本成語詞典，目錄是按成語拼音順序建立，查詢需求是，你想找以 "一"字開頭的成語（"一%"），和你想找包含一字的成語（"%一%"）
除了like，以下操作符也可用到索引：
<，<=，=，>，>=，BETWEEN，
IN<>，not in ，！=則不行複製程式碼6、什麼樣的欄位不適合建索引？
一般來說，列的值唯一性太小（如性別，型別什麼的），不適合建索引（怎樣叫太小？一半說來，同值的資料超過表的百分之15，那就沒必要建索引了）
太長的列，可以選擇只建立部分索引，（如：只取前十位做索引）
更新非常頻繁的資料不適宜建索引（怎樣叫非常？意會）
7、一次查詢能用多個索引嗎?
不能
8、多列查詢該如何建索引?
一次查詢只能用到一個索引，所以 首先槍斃 a，b各建索引方案 a還是b？誰的區分度更高（同值的最少），建誰！ 當然，聯合索引也是個不錯的方案，ab，還是ba，則同上，區分度高者，在前
9、聯合索引的問題?
where a = "xxx" 可以使用 AB 聯合索引 where b = "xxx" 則不可 （再想象一下，這是書的目錄？） 所以，大多數情況下，有AB索引了，就可以不用在去建一個A索引了
10、哪些常見情況不能用索引?
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來存手機號（為什麼？自己想！要不自己試試）
11、覆蓋索引(Covering Indexes)擁有更高效率
索引包含了所需的全部值的話，就只select 他們，換言之，只select 需要用到的欄位，如無必要，可儘量避免select *
12、NULL 的問題
NULL會導致索引形同虛設，所以在設計表結構時應避免NULL 的存在（用其他方式表達你想表達的NULL，比如 -1？）
13、如何檢視索引資訊，如何分析是否正確用到索引?
show index from tablename;
explain select ……;複製程式碼關於explain，改天可以找個時間專門寫一篇入門帖，在此之前，可以嘗試 google
14、瞭解自己的系統，不要過早優化!
過早優化，一直是個非常討厭而又時刻存在的問題，大多數時候就是因為不瞭解自己的系統，不知道自己系統真正的承載能力
比如：幾千條資料的新聞表，每天幾百幾千次的正文搜尋，大多數時候我們可以放心的去like，而不要又去建一套全文搜尋什麼的，畢竟cpu還是比人腦厲害太多
15、分享個小案例：
曾經有個朋友找板子，說：大師幫看看，公司網站打不開 板子笑了笑：大師可不敢當啊，待我看看再說 板子花了10分鐘分析了下：中小型企業站，量不大（兩三萬pv每天），獨立伺服器，資料量不大（100M不到），應該不至於太慢 某個外包團隊做的專案，年久失修，徹底改造？不現實！ 於是，板子花了20分鐘給可以加索引的欄位都加上了索引，於是，世界安靜了 朋友說：另外一個哥們說，優化至少得2w外包費，你只用30分鐘，看來，大師你是當之無愧了，選個最好的餐館吧 板子：那就來點西餐吧，常熟路地鐵站肯德基等你！
16、最後：永遠別忘記的關鍵詞 sql注入
希望本文所述對大家mysql資料庫程式設計有所幫助。
最後
歡迎大家關注我的公種浩【程式設計師追風】，整理了2019年多家公司java面試題資料100多頁pdf文件，文章都會在裡面更新，整理的資料也會放在裡面。