mysql慢查询开启及分析方法

时间：2021-04-11 09:19:05

最近服务维护的公司的DB服务器，总是会出现问题，感觉需要优化一下了，登陆上去，发现慢查询日志都没有开，真是惭愧， 故果断加上慢查询日志， 经过分析sql记录，发现问题很多，开发人员很多没有对sql优化，由于现在业务量较少，而且服务器性能配置较高，所以看不出问题。

加 上慢查询日志好后，瞬间日志暴增，讲过分析，其中80%的sql没有用到索引，执行较慢的sql及小于3秒的，没有出现，瞬间对网上好多人说，mysql 优化索引为王甚为感慨，可能你会感觉到，为什么哪里的面试都会牵涉到mysql索引优化的问题， sql优化从研发开始，如果研发团队不重视代码质量还没 有一个好的开发框架来约束开发者随意编写未经认证的sql语句，是多么的恐怖。

不扯淡了，回到正题，普及一下mysql满查询日志的操作及分析方法：

    1. 参数的意义

      log-slow-queries <slow_query_log_file>
      存放slow query日志的文件。你必须保证mysql server进程mysqld_safe进程用户对该文件有w权限。

      long_query_time
      如
      果query time超过了该值，则认为是较慢查询，并被记录下来。单位是秒，最小值是1,默认值是10秒。10秒对于大多数应用来讲，太长了。我们推
      荐从3秒开始， 依次减少，每次都找出最”昂贵”的10条SQL语句并且优化他们。日复一日，一步一步优化。一次性找出很多条SQL语句，对于优化来讲，
      意义并不大。

      log-queries-not-using-indexes
       MySQL会将没有使用索引的查询记录到slow query日志中。无论它执行有多快，查询语句没有使用索引，都会被记录。有的时候，有些没有使用引索的查询非常快(例如扫描很小的表)，但也有可能导致服务器变慢，甚至还会使用大量的磁盘空间。

      log-slow-admin-statements
      一些管理指令，也会被记录。比如OPTIMEZE TABLE, ALTER TABLE等等。

    2. 开启慢查询

      方法一：在服务器上找到mysql的配置文件my.cnf , 然后再mysqld模块里追加一下内容

      1
      2
      3
      4
      5
      log_slow_queries = NO
      log-slow-queries = /var/run/mysqld/slow_querys.log
      long_query_time = 3
      log-queries-not-using-indexes
      log-slow-admin-statements

      然后重启mysql服务器即可，这是通过一下命令看一下慢查询日志的情况：

      1
      tail -f /var/run/mysqld/slow_querys.log

      方法二：通过修改myssql的全局变量来处理，这样做的好处是，不用重启mysql服务器，登陆到mysql上执行一下sql脚本即可

      1
      2
      set global slow_query_log=ON;
      set global long_query_time=3;

      然后通过一下命令查看是否成功

      1
      2
      3
      4
      5
      6
      7
      mysql> show variables like 'long%';
      +-----------------+-----------+
      | Variable_name   | Value     |
      +-----------------+-----------+
      | long_query_time | 10.000000 |
      +-----------------+-----------+
      1 row in set (0.00 sec)
      1
      2
      3
      4
      5
      6
      7
      8
      9
      mysql> show variables like 'slow%';
      +---------------------+---------------+
      | Variable_name       | Value         |
      +---------------------+---------------+
      | slow_launch_time    | 2             |
      | slow_query_log      | ON            |
      | slow_query_log_file | /tmp/slow.log |
      +---------------------+---------------+
      3 rows in set (0.00 sec)

    3. 分析慢查询日志

      方法一：通过查看mysql的慢查询日志分析，比如我们可以tail -f  slow_query.log查看里面的内容，字段意义

      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      # Time: 110107 16:22:11
      # User@Host: root[root] @ localhost []
      # Query_time: 9.869362 Lock_time: 0.000035 Rows_sent: 1 Rows_examined: 6261774
      SET timestamp=1294388531;
      select count(*) from ep_friends;
      第一行,SQL查询执行的时间
      第二行,执行SQL查询的连接信息
      第三行记录了一些我们比较有用的信息
      Query_time SQL执行的时间,越长则越慢
      Lock_time 在MySQL服务器阶段(不是在存储引擎阶段)等待表锁时间
      Rows_sent 查询返回的行数
      Rows_examined 查询检查的行数

      方法二：使用mysqldumpslow命令分析，例如

      1
      mysqldumpslow -s c -t 10 /tmp/slow-log

      这会输出记录次数最多的10条SQL语句，其中：

      -s, 是表示按照何种方式排序，c、t、l、r分别是按照记录次数、时间、查询时间、返回的记录数来排序，ac、at、al、ar，表示相应的倒叙； -t, 是top n的意思，即为返回前面多少条的数据； -g, 后边可以写一个正则匹配模式，大小写不敏感的；

      比如
      /path/mysqldumpslow -s r -t 10 /tmp/slow-log
      得到返回记录集最多的10个查询。
      /path/mysqldumpslow -s t -t 10 -g “left join” /tmp/slow-log
      得到按照时间排序的前10条里面含有左连接的查询语句。

    4. 慢查询日志的不足

      虽然记录了slow query能够帮助你优化产品。但是MySQL目前版本，还有几大蹩足的地方。
      1.MySQL5.0版本, long_query_time时间粒度不够细,最小值为1秒。对于高并发性能的网页脚本而言，1秒出现的意义不大。即出现1秒的查询比较少。直到mysql5.1.21才提供更细粒度的long_query_time设定.

      2.不能将服务器执行的所有查询记录到慢速日志中。虽然MySQL普通日志记录了所有查询，但是它们是解析查询之前就记录下来了。这意味着普通日志没办法包含诸如执行时间，锁表时间，检查行数等信息。

      3.
      如果开启了log_queries_not_using_indexes选项，slow query日志会充满过多的垃圾日志记录，这些快且高效的全表扫
      描查询(表小)会冲掉真正有用的slow queries记录。比如select * from category这样的查询也会被记录下来。开启了
      log_queries_not_using_indexes选项，slow query日志会充满过多的垃圾日志记录，这些快且高效的全表扫描查询(表
      小)会冲掉真正有用的slow queries记录。比如select * from category这样的查询也会被记录下来。

相关文章