mysql如何查询慢的sql语句

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

这篇文章主要讲解了“mysql 如何查询慢的 sql 语句”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着丸趣 TV 小编的思路慢慢深入，一起来研究和学习“mysql 如何查询慢的 sql 语句”吧！

方法：1、若未开启慢查询，用“set global slow_query_log= ON”开启慢；2、用“set global slow_query_log_file= 路径”设置慢查询文件保存位置；3、用“subl 路径”查询文件即可。

本教程操作环境：centos 7 系统、mysql8.0.22 版本、Dell G3 电脑。

mysql 怎么查询慢的 sql 语句

Mysql 中 查询慢的 Sql 语句的记录查找

慢查询日志 slow_query_log，是用来记录查询比较慢的 sql 语句，通过查询日志来查找哪条 sql 语句比较慢，这样可以对比较慢的 sql 可以进行优化。

登陆 mysql 数据库：

1、查看一下当前的慢查询是否开启，若未开启则开启

以及慢查询所规定的时间：

show variables like  slow_query_log 
show variableslike  long_query_time

如果你的查询后的结果是 OFF 状态的话，就需要通过相关设置将其修改为 ON 状态：

set global slow_query_log= ON

将慢查询追踪的时间设置为 1s：

这里你在设置之后，这个世界是不会立即变成 1s 的，需要在数据库重启后才生效：

2、设置慢查询日志文件保存的位置：

set global slow_query_log_file= /var/lib/mysql/test_1116.log

3、查看以下配置后的文件：

sudo subl /var/lib/mysql/test_1116.log

扩展知识：

MySQL 数据库慢查询问题排查方法

最近碰到了几次数据库响应变慢的问题，整理了一下处理的流程和分析思路，执行脚本。希望对其他人有帮助。

MySQL 慢查询表现

明显感觉到大部分的应用功能都变慢，但也不是完全不能工作，等待比较长的时间还是有响应的。但是整个系统看起来就非常的卡。

查询慢查询数量

一般来说一个正常运行的 MySQL 服务器，每分钟的慢查询在个位数是正常的，偶尔飙升到两位数也不是不能接受，接近 100 系统可能就有问题了，但是还能勉强用。这几次出问题慢查询的数量已经到了 1000 多。

慢查询的数量保存在 mysql 库里面的 slow_log 表。

SELECT * FROM `slow_log` where start_time    2019/05/19 00:00:00

这样就能查出一天以来的慢查询了。

查看当前进行的查询状态

大家应该都比较常用 show processlist 来查看当前系统中正在执行的查询，其实这些数据也保存在 information_schema 库里面的 processlist 表，因此如果要做条件查询，直接查询这张表更方便。

比如查看当前所有的 process

select * from information_schema.processlist

查看当前正在进行的查询并按照已经执行时间倒排

select * from information_schema.processlist where info is not null order by time desc

正常运行的数据库，因为一条查询的执行速度很快，被我们的 select 抓到的 info 不是 null 的查询数量会很少。我们这样负荷很大的库一般也就只能查到几条。如果一次能查到 info 非空的查询有几十条，那么也可以认为系统出问题了。

系统问题和定位

当我们察觉到系统变慢之后，马上用慢查询和查看 processlist 的方式做了检查，结果发现每分钟慢查询数量飙升到 1000 多，同时淤积了大量的查询在执行中。

因为当务之急是尽快恢复系统的正常运行，因此影响最直接的做法是在 processlist 的查询结果中，查看有多少哪些查询处于 lock 状态，或者已经执行了很长时间，把这些 process 用 kill 指令干掉。通过不停的杀死这些可能会引发系统阻塞的 process，最终能够暂时让系统逐步恢复到正常状态，当然这只是权宜之计。

此外，最重要的当然是分析到底是哪些查询为什么会引发系统阻塞，我们还是使用慢查询来做分析。

慢查询表查询结果里面有几个比较重要的指标：

start_time 开始时间，要通过这个参数，配合系统出问题的时间，定位哪些查询是罪魁祸首。

query_time 查询时间

rows_sent 和 rows_examined 发送的结果数以及查询扫过的行数，这两个值特别重要，特别是 rows_examined。基本上就能告诉我们，哪个查询是需要注意的“大”查询。

实际操作中，我们也是把有大量 rows_examined 的查询一个个拿出来分析，添加索引，修改查询语句的编写，来彻底的解决问题。

处理结果和反思

经过对所有慢查询的检查和整改，目前 MySQL 每分钟慢查询数徘徊在 1~2 之间，CPU 的负荷也非常低。问题算是基本得到了解决。

反思一下问题出现的原因，有几个地方需要注意：

1，数据库出问题往往不是上线即引发问题，而是有一个累积的过程，不断累加的糟糕的查询语句会逐步增加系统负载，最后压倒骆驼的最后一根稻草往往看上去莫名其妙

2，最后的一根稻草甚至有可能根本不存在，不是一次发版或者是功能上线，而是随着用户使用量上升，数据量的累积而爆发

3，既然问题的出现是累积的过程，就需要在每次代码发版之前做好 review

4，索引的添加很重要

5，慢查询的监控也需要纳入到 Zabbix 的监控范围

感谢各位的阅读，以上就是“mysql 如何查询慢的 sql 语句”的内容了，经过本文的学习后，相信大家对 mysql 如何查询慢的 sql 语句这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是丸趣 TV，丸趣 TV 小编将为大家推送更多相关知识点的文章，欢迎关注！