MySQL慢查询日志，看完你就知道了得到如下结果：可以看到slow_query_log属性为OFF，处于关闭状态，所以我们需要先开启慢查询。slow_query_log_file表示慢查询日志文件的存放路径，我们可以自定义文件路径：setglobalslow_query_log_file='path'。2、开启慢查询日志，执行命令：setglobalslow_query_log=on。然后再查看，发现slow_query_log是开启的：开启之后，所有的查询都会记录到文件中吗？当然不是，慢查询日志，顾名思义，只记录慢查询语句，那么问题又来了，怎么算慢查询语句呢？其实这里会有一个标准值，这个标准值可以自己设定。3、慢查询的阈值设置首先查看默认的阈值。执行命令：showvariableslike'%long%'。有一个值为10.000000的long_query_time属性。意思是只记录查询时间大于10s的语句。显然10s是我们不能接受的，所以我们需要自己设置这个值。因为我自己的测试表只有10w条数据，查询很快，所以这里我们设置一个较小的值。如果可能，最好设置百万级别的表进行测试。我们将慢查询阈值设置为0.02：设置long_query_time=0.02。可以看出现在的临界值为0.02秒。现在我们模拟两个查询时间小于0.01和大于0.01的查询，看是否都记录在慢查询日志中。再看日志文件中的数据：只能看到第二次查询的日志。需要说明的是，以上操作都是在交互界面上进行的。如果重新启动数据库，这些设置将失效。如果想永久生效，需要修改配置文件：vi/etc/my.cnf[mysqld]slow_query_log=1long_query_time=0.1slow_query_log_file=/usr/local/mysql/mysql_slow.log在配置中加入这三行文件。主要是重启mysql生效！慢查询语句分析我们可以通过慢查询日志定位到是哪条语句查询慢。找到这条语句后，如何分析它慢的原因呢？最简单的方法是使用explainAnalysis。执行命令：explain(sql语句)。我们来对比分析上面执行的两条语句：我们需要重点关注possible_keys、key、rows的属性值。possible_keys表示语句可能使用索引。key代表语句实际使用的索引。rows表示语句扫描的行数。通过这些属性我们可以大致分析出，第一条语句没有使用索引，扫描了9万多行数据，所以查询速度比较慢，而第二条语句使用了主键索引，只扫描了一条语句。所以它执行得更快。这样，我们就可以快速定位问题，然后有针对性地解决问题。启用性能细节如果上面的语句分析没有定位到问题，我应该加的索引也加了，但是还是比较慢，那么可以通过性能细节进一步探究原因。性能详情可以跟踪查询语句整个生命周期的状态。有了这些状态值，就可以更深层次地找出是哪条链路慢了，从而有针对性地进行改进。1、查看性能详情是否开启，执行命令：showvariableslike'%profiling%'。可以看到profiling属性值为OFF，表示关闭，我们先开启。执行命令：setprofiling=on。就是这样。开启后，我们可以执行查询语句，mysql会自动保存性能记录。2、查看性能记录，我们执行一条sql语句：然后查看性能记录：执行命令：showprofiles。开启后可以看到所有查询语句的记录。我们要查看第二条执行语句整个执行周期的状态详情：执行命令：showprofileforquery2可以看到整个执行过程中各个状态的耗时情况。然后定位到哪个状态最耗时，然后有针对性的排查原因。官方也给出了每个状态的解释，详情可以查看：https://dev.mysql.com/doc/refman/5.7/en/general-thread-states.html。
