是否會使用索引，是mysql的關鍵
1.sql性能下降原因
- 查詢語句寫的不好，連接子查詢太多，沒有建索引等等
- 索引失效
- 關聯Jion表過多
- 服務器參數設置不合適
2.索引優化
索引是什麼？
索引就是一種排好序的查找數據結構，常見模型有哈希表、有序數組、二叉搜索樹
目前最常用的innoDB引擎使用的模型是B+Tree，也就是多叉搜索樹（葉子節點是指針，指向數據地址）
如何建索引（也可以用Alter）
假如表結構 id name email phonenumber
select * from user where name =‘’;
單值索引：create index idx_user_name on user(name)
select * from user where name =‘’ and email;
複合索引：create index idx_user_nameEmail on user(name,email)
唯一索引：列值唯一，可以爲空
索引好處壞處
好處就是減少IO和CPU消耗
壞處就是佔用空間、更新消耗增加、優化索引耗時
3.什麼時候建索引
什麼時候建
- 主鍵自動建索引，外鍵要建
- where經常用到的要建，where用不到的不建
- 排序、統計、分組的字段建立索引（order,group by等）
什麼時候不建
- 頻繁修改的列值
- 表記錄太少
- 列值重複過多
4.Explain 性能分析
架構
連接器：通過連接器連接數據庫
查詢緩存：MySQL拿到一個查詢請求後，會先到查詢緩存看看，之前是不是執行過這條語句，執行過的直接緩存在內存中；如果查詢命中緩存，MySQL不需要執行後面的複雜操作，就可以直接返回結果。
優化器： 跟指令重排類似，會選擇最優方案
執行器：調用引擎
存儲引擎：默認innoDB,還有MyISAM、MEMORY等
是什麼
模擬優化器執行SQL語句，從而分析SQL
怎麼做
Explain+SQL
結果如下
4.1 參數詳解
id:選擇標識符，可以理解爲一組，如果是子查詢，id的序號會遞增，id值越大優先級越高，越先被執行
select_type:表示查詢的類型。比如SIMPLE-簡單SELECT，不使用UNION或子查詢等
table:輸出結果集的表
type:對錶訪問方式，表示MySQL在表中找到所需行的方式，又稱“訪問類型”。，常用的類型有： ALL、index、range、 ref、eq_ref、const、system、NULL（從左到右，性能從差到好）
possible_keys:表示查詢時，可能使用的索引
key:表示實際使用的索引
key_len:索引字段的長度，表示索引中使用的字節數
ref:列與索引的比較，即哪些列或常量被用於查找索引列上的值
rows:掃描出的行數(估算的行數) 估算出結果集行數
Extra:執行情況的描述和說明
Using where:不用讀取表中所有信息，僅通過索引就可以獲取所需數據，這發生在對錶的全部的請求列都是同一個索引的部分的時候，表示mysql服務器將在存儲引擎檢索行後再進行過濾
Using temporary：表示MySQL需要使用臨時表來存儲結果集，常見於排序和分組查詢，常見 group by ; order by
Using filesort：當Query中包含 order by 操作，而且無法利用索引完成的排序操作稱爲“文件排序”
Using join buffer 使用了連接緩存
Using filesort 使用一個外部的索引排序
Using index 使用了覆蓋索引
單表和多表索引優化
單表
兩表
左連接的索引加到JOIN後面的表中效果更好，也就是加到右表，因爲左連接條件用於如何從右表搜索行，左表都有
5.索引失效的情況
導圖
- 全值匹配：建立的複合索引中的索引全部都要用到，纔是最好的
- 最佳左前綴法則：如果是複合索引，要遵守查詢從索引的最左前列開始並且不跳過索引中的列
- 不在索引列做任何操作，如計算、函數、類型轉換：比如left(索引)等函數
- 存儲引擎不能使用索引中範圍條件右邊的列：從範圍條件開始索引開始失效，比如id>‘10’
- 儘量使用覆蓋索引，減少select *，select後面的搜索目標要準確
- mysql在使用不等於的時候無法使用索引：比如 is_null!=0
- is null is not null 無法使用索引： 比如 where id is null
- like 通配符在前,like使用通配符最好是索引在前，&索引 索引會失效
- 字符串不加單引號索引失效：會發生類型轉換
- Or連接導致索引失效 ：儘量少使用or