1.如何定位並優化慢查詢sql
a.根據慢日志定位慢查詢sql
SHOW VARIABLES LIKE '%query%' 查詢慢日志相關信息
slow_query_log 默認是off關閉的，使用時，需要改為on 打開
slow_query_log_file 記錄的是慢日志的記錄文件
long_query_time 默認是10S，每次執行的sql達到這個時長，就會被記錄
SHOW STATUS LIKE '%slow_queries%' 查看慢查詢狀態
Slow_queries 記錄的是慢查詢數量 當有一條sql執行一次比較慢時，這個vlue就是1 （記錄的是本次會話的慢sql條數）
注意：
如何打開慢查詢 ： SET GLOBAL slow_query_log = ON;
將默認時間改為1S： SET GLOBAL long_query_time = 1;
（設置完需要重新連接數據庫，PS：僅在這里改的話，當再次重啟數據庫服務時，所有設置又會自動恢復成默認值，永久改變需去my.ini中改）
b.使用explain等工具分析sql
在要執行的sql前加上explain 例如：EXPLAIN SELECT menu_name FROM t_sys_menu ORDER BY menu_id DESC;
接着看explain的關鍵字段
type：
如果發現type的值是最后兩個中的其中一個時，證明語句需要優化了。
extra：
c.修改sql或者盡量讓sql走索引
mysql查詢優化器會根據具體情況自己判斷走哪個索引，不一定是走主鍵（explain中的key可以看到走的哪個key）具體情況根據具體情況來定，當你要強制執行走某一個key時：
在查詢的最后加上 force index(primary); 強制走主鍵的
2.聯合索引的最左匹配原則的成因
最左匹配原則的概念參考：
https://www.cnblogs.com/lanqi/p/10282279.html
成因：
當通過（col3，col2）這樣的聯合索引去查找時，可以看到也是一個B+樹的結構向下查找，若直接通過col2去查找，無法直接查找到34、77。也就用不到這個聯合索引了。
3.索引是建立得越多越好嗎
1.數據量小的表不需要建立索引，建立會增加額外的索引開銷。
2.數據變更需要維護索引，因此更多的索引意味着更多的維護成本。
3.更多的索引意味着也需要更多的空間。