文章目录
- 8.在MySQL中,如何定位慢查询以及对应解决方法?
- 8.1MySQL慢查询日志
- 8.1.1开启慢查询
- (1)修改配置文件
- (2)设置全局变量
- 8.1.2日志记录在表上(实践)
- 8.1.3日志记录在文件上(实践)
- (1)mysqldumpslow
- 8.2深度分析慢SQL
- 8.2.1问题
- 8.2.2步骤一:分析SQL执行计划
- 8.2.3索引优化
8.在MySQL中,如何定位慢查询以及对应解决方法?
- 三种方法定位慢查询
- Skywalking工具:实时监控接口性能,一眼锁定“拖油瓶”。报表详列各接口及内部组件耗时,尤其关注SQL执行时间,迅速圈定问题SQL;
- MySQL内置慢查询日志;
8.1MySQL慢查询日志
-
慢查询日志是 MySQL 内置的一项功能,可以记录执行超过指定时间的 SQL 语句。
-
以下是慢查询的相关参数,大家感兴趣的可以看下:
参数 含义 log_output 日志输出位置,默认为 FILE,即保存为文件,若设置为 TABLE,则将日志记录到 mysql.show_log 表中,支持设置多种格式 slow_query_log_file 指定慢查询日志文件的路径和名字,可使用绝对路径指定,默认值是主机名-slow.log,位于配置的 datadir 目录 long_query_time 执行时间超过该值才记录到慢查询日志,单位为秒,默认为 10 min_examined_row_limit 对于查询扫描行数小于此参数的SQL,将不会记录到慢查询日志中,默认为 0 log_queries_not_using_indexes 是否将未使用索引的 SQL 记录到慢查询日志中,开启此配置后会无视 long_query_time 参数,默认为 OFF log_throttle_queries_not_using_indexes 设定每分钟记录到日志的未使用索引的语句数目,超过这个数目后只记录语句数量和花费的总时间,默认为 0 log-slow-admin-statements 记录执行缓慢的管理 SQL,如 ALTER TABLE、ANALYZE TABLE、CHECK TABLE、CREATE INDEX、DROP INDEX、OPTIMIZE TABLE 和 REPAIR TABLE,默认为 OFF log_slow_slave_statements 记录从库上执行的慢查询语句,如果 binlog 的值为 row,则失效,默认为 OFF
8.1.1开启慢查询
有两种方式可以开启慢查询
- 修改配置文件
- 设置全局变量
(1)修改配置文件
-
修改配置文件 my.ini,在[mysqld]段落中加入如下参数:
[mysqld] log_output='FILE,TABLE' slow_query_log='ON' long_query_time=0.001
-
然后需要重启 MySQL 才可以生效,命令为
service mysqld restart
(永远生效)
(2)设置全局变量
- 无需重启即可生效,但是重启会导致设置失效,设置的命令如下所示:
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL log_output = 'FILE,TABLE';
SET GLOBAL long_query_time = 0.001;
8.1.2日志记录在表上(实践)
- 通过第二种方式:设置全局变量开启慢查询;
- 使用全表查询语句:SELECT * FROM user;
- 然后再查询慢查询日志:
SELECT * FROM mysql.slow_log
,可以发现其中有这样一条记录:
- 这样我们就可以通过 slow_log 表的数据进行分析,然后对 SQL 进行调优了。
8.1.3日志记录在文件上(实践)
- 若将日志记录在文件上,使用
SHOW VARIABLES LIKE '%slow_query_log_file%'
来查看文件保存位置; - 可以看出每五行表示一个慢 SQL,这样查看比较费事,可以使用一些工具来查看。
(1)mysqldumpslow
MySQL 内置了 mysqldumpslow 这个工具来帮助我们分析慢查询日志文件,Windows 环境下使用该工具需要安装 Perl 环境。
可以通过 -help
来查看它的命令参数:
mysqldumpslow help
比如我们可以通过 mysqldumpslow -s t 10 LAPTOP-8817LKVE-slow.log
命令得到按照查询时间排序的 10 条 SQL 。
8.2深度分析慢SQL
8.2.1问题
定位到慢SQL后,如何进行深度分析?
8.2.2步骤一:分析SQL执行计划
- 使用explain命令分析SQL执行计划:
- Key & Key_len:确认索引是否生效。若已建索引未被充分利用,可能存在失效问题。
- Type:扫视查询类型,警惕全表扫描(All/Full Scan)等低效访问模式,寻找优化突破口。
- rows:预计需要扫描的记录数,预计需要扫描的记录数越小越好
- Extra:留意MySQL给出的执行建议,如“Using filesort”、“Using temporary”等,提示可能存在的额外排序、临时表操作,影响性能。
8.2.3索引优化
- 针对上述分析结果:
- 修复失效索引:添加缺失索引,调整或重建现有索引。
- 解决回表查询问题:若发现回表现象,尝试增加覆盖索引(一次查询,就查到了全部需要的数据,避免 SELECT *)或减少SELECT字段,减轻IO压力。