共计 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.log3、查看以下配置后的文件：
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 小编将为大家推送更多相关知识点的文章，欢迎关注！
