在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的文章，感谢各位阅读。