近期打算啃一啃Mysql，談到數據庫總是繞不過查詢速度，Mysql 因其開源等的緣故，在各個關係型數據庫中脫穎而出。這篇文章主要是對這段時間的學習mark 一下。如果還對看到這篇文章的你， 能有所幫助， 那就再好不過了。
進行優化，需要先了解explain 使用。執行SQL 語句只需要在執行查詢語句前，添加 “explain” 關鍵字
explain + SQL語句
簡介參照以下描述
1，id
id值不同，越大越先查詢。如果查詢包含子查詢，id值會不一樣。（本質：嵌套查詢時，先查內層再查外層），id值有相同有不同
2，select_type:查詢類型
Primary key :包含子查詢SQL中的主查詢（最外層）；
SUBQUERY：包含子查詢SQL的子查詢（非最外層）；
simple：簡單查詢（不包含子查詢、union）
derived：衍生查詢（使用了臨時表）a. 在from 子查詢中只有一張表select * from ( select * from course where tid in (1,2)) cr;
b. 在from子查詢中，如果有table1 union tables2, 則table1 就是derived， table2 就是unionselect cr.cname from ( select * from course where tid =1 union select * from course where tid =2 ) cr3，Type: 類型或者索引類型
System>const>eq_ref>ref>range>index>all
System,const 只是理想情況；實際能達到 ref 或者range
System:只有一條數據的系統表；或衍生表只有一條數據的主查詢
const:僅僅能查到一條數據的SQL，用於Primary key或者unique
eq_ref: 唯一性索引鍵的查詢，返回匹配唯一行數據ref ->非唯一性索引，對於每個索引鍵的查詢，返回匹配的所有行
range:只檢索給定範圍的行，使用一個索引來選擇行 > ref: 表示上述表的連接匹配條件，即哪些列或常量被用於查找索引列上的值4，key_len
表示索引中使用的字節數，可通過該列計算查詢中使用的索引的長度（key_len顯示的值爲索引字段的最大可能長度，並非實際使用長度，即key_len是根據表定義計算而得，不是通過表內檢索出的）
不損失精確性的情況下，長度越短越好>5，key
key列顯示MySQL實際決定使用的鍵（索引）
6，ExtraUsing filesort （文件內排序，“多了一次額外的查找/排序”）: 不要跨列使用（where 和order by）
explain select a1, a2, a3, a4 from test03 where a1 = 1 and a4 = 4 order by a2, a3;
Using where : 需要回原表Using index：不需要回原表
Using index：不需要回原表
explain 多用於分析索引創建的合理性，但是Mysql 內置的sql優化器也會進行一些它自認爲好的優化。
以下是根據explian 參數展示索引跨列使用對性能影響。
1.創建a1,a2,a3,a4 的複合索引，進行簡單的查詢，分析計劃如下. 根據extre 和key 的值，確認該SQL 語句使用了複合索引
2，修改SQL 語句–> 查詢條件爲a1,a2,a4，這個跨列查詢，分析結果爲key_len 爲8 和 ref 中僅有四個const.
Point.1 中正常使用複合索引，key_len 爲16（每個字段的長度爲4字節） 和 ref 中包含四個const.
僅有a1,a2 索引有效，a4 因爲跨列需要返回原表查詢（根據extra 包含 using where）,導致索引失效。但是where和order by 拼起來爲a1,a2,a3 並沒有跨列，拼起來跨列的情況參照Point.3
3. 刪除查詢條件語句中的 a2，where 和 order by 拼起來 爲a1、 a3，爲跨列使用，Extra 出現了Using filesort。 出現了Using filesort， 表明多了一次額外的查詢/排序，性能較差
總結：
1，如果（a,b,c,d）複合索引 和使用的順序全部一致（且不跨列使用），則複合索引全部使用。如果部分一致，則部分使用。
2，索引一旦進行升級優化，需要將之前廢棄的索引刪掉，防止干擾。drop index idx_bta on book;
3，最佳左前綴，保持索引的定義和使用的順序一致性
4，索引需要逐步優化
* 該文章參照了 相關 Mysql 視頻學習