跳至主要內容

MySQL优化之慢日志查询

张威大约 4 分钟mysqlmysql日志

MySQL优化之慢日志查询

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

我们可以打开慢查询日志

慢查询使用方法

根据具体的业务并发量,设置好后开启业务,压测后打开慢查询日志,就会看到超过执行时间的SQL,然后使用explain分析这些耗时的SQL语句

步骤如下:

  1. 打开慢查询日志开关slow_query_log
  2. 设置合理的、业务可以接受的慢查询时间上限
  3. 压测执行各种业务
  4. 查看慢查询日志,找出所有执行耗时的SQL语句
  5. 用explain分析这些耗时的SQL语句,从而针对性优化

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

慢查询日志相关的参数

(MySQL定义的很多的全局的开关,都是在全局变量中存储,可以用show/set variables查看或者设置全局变量的值

show variables like '%slow_query%';
  • 慢查询日志开关默认是关闭的
  • 慢查询日志的路径:默认在/var/lib/mysql/

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

慢查询日志实践

1. 打开慢查询日志开关slow_query_log

1. 打开慢查询日志开关slow_query_log

show variables like 'slow_query%';
set global slow_query_log=on;
  • 在打开慢查询日志开关的时候,报错表示slow_query_log是一个global的变量(也有只影响当前session的变量,如:long_query_time 、profiling),修改后会影响所有的session,即影响所有正在访问当前MySQL server的客户端。

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

show variables like 'long_query%';
set long_query_time=0.1;

查看另一个session,发现还是默认的10s,故long_query_time只影响当前session

3. 压测执行各种业务

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

4. 查看慢查询日志

路径:/var/lib/mysql/

  • 需要sudo 权限才能查看

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

做了整表扫描,把有序链表整个扫了一遍。

我们应该给

  1. password添加索引,

  2. password是

create index passwordidx on t_user(password);
select * from t_user where password='1500000';

其他比如涉及

show profiles查看sql具体的运行时间/更详细的时间

MySQL一般只显示小数点后两位的时间

打开profiling开关,显示更详细的时间

set profiling = ON; #profiling变量只影响当前session
show profiles; #展示SQL语句精细的耗时时间