MySQL5.6 怎样优化慢查询的SQL语句 -- SQL优化

2018/04/04 08:59
阅读数 21

上篇:MySQL5.6 怎样优化慢查询的SQL语句 -- 慢日志介绍

在实际的日志分析中,通常慢日志的log数量不少,同一时候同样的查询被记录的条数也会非常多。这里就须要怎样从慢日志查询中找到最有问题,最须要优化的日志。在这方面,有非常多分析工具,最主要的分析工具就是MySQL自带的mysqldumpslow,mysqldumpslow(Perl脚本)的输出演示样例:

[root@cloudlu bin]# ./mysqldumpslow -s t -t 1 /usr/local/mysql/data/cloudlu-slow.log

Reading mysql slow query log from /usr/local/mysql/data/cloudlu-slow.log
Count: 1  Time=0.00s (0s)  Lock=0.00s (0s)  Rows=3.0 (3), root[root]@localhost
  select * from t
一看就非常清楚。它的输出主要 统计不同慢sql的出现次数(Count 1),运行最长时间(Time 0.00s),累计总耗费时间(Time 0s),等待锁的时间(Lock 0.00s),等待锁的总时间(Lock 0s)。 发送给client的行总数(Rows 3.0),扫描的行总数(Rows 3),用户(root)以及sql语句本身。它最经常使用的參数包含:

-s 排序选项:c 查询次数 r 返回记录行数 t 查询时间 
-t n:显示top n条查询


对于一般的分析已经几乎相同了,只是对于百分比等等数据mysqldumpslow就不够完好了。所以世界上多了非常多各种MySQL慢日志分析工具,比較优秀的有mysqlsla(Perl脚本)pt-query-digest(Perl脚本)。能够提供Count, sql的运行次数及占总的slow log数量的百分比。Time, 运行时间, 包含总时间, 平均时间, 最小, 最大时间, 时间占到总慢sql时间的百分比,95% of Time, 去除最快和最慢的sql, 覆盖率占95%的sql的运行时间,Lock Time, 等待锁的时间,95% of Lock , 95%的慢sql等待锁时间,Rows sent, 结果行统计数量, 包含平均, 最小, 最大数量,Rows examined, 扫描的行数量,还能够生成表报。存储分析结果。这里就不一一介绍了。



通过这些慢日志分析软件定位到了慢查询语句就已经完毕了SQL优化的一大半。接下来通过在MySQL中运行explain或者desc命令查看慢查询语句,能够看出为什么SQL查询慢。

mysql> explain select * from test.t \G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: t
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 2
        Extra: NULL
1 row in set (0.00 sec)

它的输出格式细节能够关注MySQL explain format。在输出中最要注意的是:

1. type:ALL是效率最差,最要注意的

2. key:是否有使用Key,key长度怎样

3. Extra:最好不要出现filesort以及temporary。最主要是要关注在orderby和groupby。


Note: SQL优化是个非常复杂的过程,有可能出现拆东墙补西墙的情况:比方给数据库表添加了索引之后。确实查询快了,但是存储空间加多了,插入删除操作耗时也添加了,假设在一个写多读少的系统中,运行这样的优化可能会起到反效果。所以优化完之后千万不能大意。要持续监控系统。防止出现引入新瓶颈的情况。

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部