MySQL慢日志查询实例分析

130次阅读

没有评论

共计 1416 个字符，预计需要花费 4 分钟才能阅读完成。

本篇内容介绍了“MySQL 慢日志查询实例分析”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让丸趣 TV 小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！

一、慢查询日志概念

对于 SQL 和索引的优化问题，我们会使用 explain 去分析 SQL 语句。但是真正的企业级项目有成千上万条 SQL，我们不可能从头开始一条一条 explain 去分析。我们从什么地方可以获取那些运行时间长，耗性能的 SQL？？

我们可以打开慢查询日志：

根据具体的业务和并发量来预估一个时间上限（20ms、100ms），设置好后开启业务，压测后打开慢查询日志，就会看到超过执行时间的 SQL，然后使用 explain 分析这些耗时的 SQL 语句

步骤如下：

打开慢查询日志开关 slow_query_log

设置合理的、业务可以接受的慢查询时间上限

压测执行各种业务

查看慢查询日志，找出所有执行耗时的 SQL 语句

用 explain 分析这些耗时的 SQL 语句，从而针对性优化

MySQL 可以设置慢查询日志，当 SQL 执行的时间超过我们设定的时间，那么这些 SQL 就会被记录在慢查询日志当中，然后我们通过查看日志，用 explain 分析这些 SQL 的执行计划，来判定为什么效率低下，是没有使用到索引？还是索引本身创建的有问题？或者是索引使用到了，但是由于表的数据量太大，花费的时间就是很长，那么此时我们可以把表分成多个小表等。

慢查询日志相关的参数如下所示：
（MySQL 定义的很多的全局的开关，都是在全局变量中存储，可以用 show/set variables 查看或者设置全局变量的值）

慢查询日志开关默认是关闭的
慢查询日志的路径：默认在 /var/lib/mysql/ 下

慢查询日志记录了包含所有执行时间超过参数 long_query_time（单位：秒）所设置值的 SQL 语句的日志，在 MySQL 上用命令可以查看，如下：

这个值是可以修改的：

二、慢查询日志实践 1. 打开慢查询日志开关 slow_query_log

在打开慢查询日志开关的时候，报错表示 slow_query_log 是一个 global 的变量（也有只影响当前 session 的变量，如：long_query_time、profiling），修改后会影响所有的 session，即影响所有正在访问当前 MySQL server 的客户端。

打开慢查询日志开关成功！

2. 设置合理的、业务可以接受的慢查询时间上限 long_query_time

查看另一个 session

发现还是默认的 10s，故 long_query_time 只影响当前 session

3. 压测执行各种业务

已经超过我们设置的 long_query_time=0.1s