在Mysql中執行Sql語句經常會遇到有的語句執行時間特別長的情況，出現了這種情況我們就需要靜下心分析分析。
首先，我們需要確定系統中哪些語句執行時間比較長。這個可以使用Mysql的慢日誌來跟蹤。下面給出一段SQL示例：
首先準備一個數據庫，這裏有現成的數據：
https://github.com/grezbo/cn_zipcode
數據準備好了，我們先看下mysql中關於慢日誌的系統變量（慢日誌默認是沒有開啓的，而我這裏已經開啓了)
show variables like 'slow%'
如果看到slow_query_log是OFF，那就需要手動開啓
set global slow_query_log = ON;
再看下當前將超過多少時間的sql作爲慢日誌
show variables like 'long%';
我這裏目前是1s，可以設置：set long_query_time = 0.1;
最後看下當前session記錄的慢日誌次數：
show status like '%slow_q%';
我這裏當前已經執行了3次慢查詢
好啦，前期工作準備好了，接下來我們可以執行一條語句了：
select * from zip_code order by district, area;
這條語句執行了1.745s，已經達到了慢查詢的標準，應該被記錄下來，所以我們查看一下狀態變量Slow_queries
已經變成了4，說明該條語句確實被記錄了下來，那麼我們去看下慢查詢語句所在的文件
在slow_query_log_file這個路徑下面
可以看到這裏就是我們剛纔執行那條語句，可以看到真實執行的時間是1.743617。
到這一步，我們定位了慢SQL，接下來就是對SQL語句進行分析了。有經驗人看幾眼SQL可能就知道問題在哪兒了，
我做不到。。。。我一般採用分段分析和用explain命令來分析。
對剛纔那條語句使用explain：
explain select * from zip_code order by district, area;
這條命令返回的特別快，因爲它並不會去執行SQL語句，只是分析語法優化器最終會採用什麼策略來執行SQL語句。
這裏面可以看到該條SQL有沒有走索引，用的什麼來排序，用了那個索引等等，具體可以參考其他博文，我就沒必要再貼出來了
https://www.cnblogs.com/yycc/p/7338894.html
優化的原則是查詢要儘量走索引，避免過多的回表和全表掃描的發生；儘量不要用*號，儘量帶上where條件。
以上是一篇很簡單的關於分析慢SQL的文章，感謝各位閱讀。