性能下降原因
當數據庫中的數據量還不是很大的時候，SQL語句的執行時間還是可以接受的，但是當數據量達到幾百萬的時候，由於SQL語句執行時間長、等待時間長就會造成MySQL的性能下降，產生的原因有如下幾點：
- 查詢語句寫的爛（沒有創建索引）
- 索引失效（索引分單值索引和複合索引）
- 關聯查詢太多join（設計缺陷或不得已的需求）
- 服務器調優及各個參數設置（緩衝，線程數等）
索引簡介
索引的定義：MySQL官方對索引的定義爲：索引（Index）是幫助MySQL高效獲取數據的數據結構。
因此可以得到索引的本質：索引是數據結構。
可以簡單理解爲“排好序的快速查找的數據結構”。
索引圖示
在數據之外，數據庫系統還維護着滿足特定查找算法的數據結構，這些數據結構以某種方式引用（指向）數據，這樣就可以在這些數據結構上實現高級查找算法。這種數據結構，就是索引。下圖就是一種可能的索引方式示例：
爲了加快Col2的查找，可以維護一個右邊所示的二叉查找樹，每個節點分別包含索引鍵值和一個指向對應數據記錄物理地址的指針，這樣就可以運用二叉查找在一定的複雜度內獲取到相應數據，從而快速的檢索出符合條件的記錄。
一般來說索引本身也很大，不可能全部存儲在內存中，因此索引往往以索引文件的形式存儲在磁盤上。
我們平常所說的索引，如果沒有特別指明，都是指B樹(多路搜索樹，並不一定是二叉的)結構組織的索引。其中聚集索引，次要索引，覆蓋索引，複合索引，前綴索引，唯一索引默認都是使用B+樹索引，統稱索引。當然，除了B+樹這種類型的索引之外，還有哈希索引(hash index)等。
索引的優勢和劣勢
優勢：
1.類似大學圖書館建書目索引，提高數據檢索的效率，降低數據庫的IO成本
2.通過索引列對數據進行排序，降低數據排序的成本，降低了CPU的消耗
劣勢：
1.實際上索引也是一張表，該表保存了主鍵與索引字段，並指向實體表的記錄，所以索引列也是要佔用空間的
2.雖然索引大大提高了查詢速度，同時卻會降低更新表的速度，如對錶進行INSERT、UPDATE和DELETE。因爲更新表時，MySQL不僅要保存數據，還要保存一下索引文件每次更新添加了索引列的字段，都會調整因爲更新所帶來的鍵值變化後的索引信息
3.索引只是提高效率的一個因素，如果你的MySQL有大數據量的表，就需要花時間研究建立最優秀的索引，或優化查詢語句
索引分類
主鍵索引：設定爲主鍵後數據庫會自動建立索引，innodb爲聚簇索引
單值索引：即一個索引只包含單個列，一個表可以有多個單列索引
唯一索引：索引列的值必須唯一，但允許有空值
複合索引：即一個索引包含多個列
索引語法
創建：
CREATE [UNIQUE] INDEX indexName ON mytable(columnname(length));
ALTER TABLE mytable ADD [UNIQUE] INDEX [indexName] ON (columnname(length))
刪除：DROP INDEX [indexName] ON mytable;
查看：SHOW INDEX FROM table_name\G;
使用ALTER命令：
有四種方式來添加數據表的索引：
ALTER TABLE tbl_name ADD PRIMARY KEY (column_list): 該語句添加一個主鍵，這意味着索引值必須是唯一的，且不能爲NULL。
ALTER TABLE tbl_name ADD UNIQUE index_name (column_list): 這條語句創建索引的值必須是唯一的（除了NULL外，NULL可能會出現多次）。
ALTER TABLE tbl_name ADD INDEX index_name (column_list): 添加普通索引，索引值可出現多次。
ALTER TABLE tbl_name ADD FULLTEXT index_name (column_list):該語句指定了索引爲 FULLTEXT ，用於全文索引。
索引結構
分類
BTree索引
B+Tree索引
聚族索引與非聚族索引
full-text全文索引
Hash索引
R-Tree索引
在幾種常見的分類中，比較重要的索引爲BTree索引。
BTree索引的檢索原理
【初始化介紹】
一顆b樹，淺藍色的塊我們稱之爲一個磁盤塊，可以看到每個磁盤塊包含幾個數據項（深藍色所示）和指針（黃色所示），
如磁盤塊1包含數據項17和35，包含指針P1、P2、P3，
P1表示小於17的磁盤塊，P2表示在17和35之間的磁盤塊，P3表示大於35的磁盤塊。
真實的數據存在於葉子節點即3、5、9、10、13、15、28、29、36、60、75、79、90、99。
非葉子節點不存儲真實的數據，只存儲指引搜索方向的數據項，如17、35並不真實存在於數據表中。
【查找過程】
如果要查找數據項29，那麼首先會把磁盤塊1由磁盤加載到內存，此時發生一次IO，在內存中用二分查找確定29在17和35之間，鎖定磁盤塊1的P2指針，內存時間因爲非常短（相比磁盤的IO）可以忽略不計，通過磁盤塊1的P2指針的磁盤地址把磁盤塊3由磁盤加載到內存，發生第二次IO，29在26和30之間，鎖定磁盤塊3的P2指針，通過指針加載磁盤塊8到內存，發生第三次IO，同時內存中做二分查找找到29，結束查詢，總計三次IO。
真實的情況是，3層的b+樹可以表示上百萬的數據，如果上百萬的數據查找只需要三次IO，性能提高將是巨大的，如果沒有索引，每個數據項都要發生一次IO，那麼總共需要百萬次的IO，顯然成本非常非常高。
索引適用場景
哪些情況適合建索引
- 主鍵自動建立唯一索引
- 頻繁作爲查詢條件的字段應該創建索引(如銀行系統的銀行卡號，電信系統的手機號)
- 查詢中與其它表關聯的字段，外鍵關係建立索引
- 單值/組合索引的選擇問題，which？(在高併發下傾向創建組合索引)
- 查詢中排序的字段，排序字段若通過索引去訪問將大大提高排序速度
- 查詢中統計或者分組字段
哪些情況不適合建索引
- 表記錄太少
- 經常增刪改的表（索引提高了查詢速度，同時卻會降低更新表的速度，如對錶進行INSERT、UPDATE和DELETE。因爲更新表時，MySQL不僅要保存數據，還要保存一下索引文件）
- Where條件裏用不到的字段不創建索引
- 數據重複且分佈平均的表字段，因此應該只爲最經常查詢和最經常排序的數據列建立索引。注意，如果某個數據列包含許多重複的內容，爲它建立索引就沒有太大的實際效果。
說明：假如一個表中有10萬條記錄，有一個字段A只有T和F兩種值，且每個值的分佈概率大約爲50%，那麼對這種表A字段建索引一般不會提高數據庫的查詢速度。
索引的選擇性是指索引列中不同值的數目與表中記錄數的比。如果一個表中有2000條記錄，表索引列有1980個不同的值，那麼這個索引的選擇性就是1980/2000=0.99。一個索引的選擇性越接近於1，這個索引的效率就越高。