MySQL慢SQL优化-如何分析性能瓶颈

来源:互联网 发布:招商银行外汇交易软件 编辑:程序博客网 时间:2024/05/22 01:52

优化慢SQL首先得知道瓶颈在哪,本文主要介绍慢SQL性能瓶颈分析。本文就以前段时间参加的一个SQL优化活动为例。
mysql命令行或者一些可视化工具在sql执行时间的精度比较低,尤其是命令行只显示到10ms,所以需要打开mysql的执行时间监听

 set profiling = 1;

然后使用

show profiles;

命令就可查看sql的执行时间。

例如:

mysql> show profiles;+----------+------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+| Query_ID | Duration   | Query                                                                                                                                           |+----------+------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+|        1 | 0.18553425 | select a.seller_id,a.seller_name,b.user_name,c.state   from  a,b,cwhere  a.seller_name=b.seller_name  and    b.user_id=c.user_id   and  c.user_id=17  anda.gmt_create BETWEEN DATE_ADD(NOW(), INTERVAL - 600 MINUTE) AND  DATE_ADD(NOW(), INTERVAL 600 MINUTE)  order  by  a.gmt_create |+----------+------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+1 row in set, 1 warning (0.00 sec)

在命令行中执行完sql后,使用 show profiles; 语句就可显示上面的执行历史信息,找到对应的,可以看到我刚测试的执行了0.18553425s这个精度就相当高。
接下来我们使用explain语句分析这条语句在所牵连的表中一共遍历了多少纪录

mysql> explain    -> select a.seller_id,a.seller_name,b.user_name,c.state   from  a,b,c    -> where  a.seller_name=b.seller_name  and    b.user_id=c.user_id   and  c.user_id=17  and    -> a.gmt_create BETWEEN DATE_ADD(NOW(), INTERVAL - 600 MINUTE) AND  DATE_ADD(NOW(), INTERVAL 600 MINUTE)  order  by  a.gmt_create    -> ;+----+-------------+-------+------------+------+---------------+------+---------+------+--------+----------+----------------------------------------------------+| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows   | filtered | Extra                                              |+----+-------------+-------+------------+------+---------------+------+---------+------+--------+----------+----------------------------------------------------+|  1 | SIMPLE      | a     | NULL       | ALL  | NULL          | NULL | NULL    | NULL |  16108 |    11.11 | Using where; Using temporary; Using filesort       ||  1 | SIMPLE      | b     | NULL       | ALL  | NULL          | NULL | NULL    | NULL |  16592 |    10.00 | Using where; Using join buffer (Block Nested Loop) ||  1 | SIMPLE      | c     | NULL       | ALL  | NULL          | NULL | NULL    | NULL | 359382 |     1.00 | Using where; Using join buffer (Block Nested Loop) |+----+-------------+-------+------------+------+---------------+------+---------+------+--------+----------+----------------------------------------------------+3 rows in set, 1 warning (0.00 sec)

这里有一个介绍的对这个结果各个列介绍比较好的网页explain结果介绍

从上面的分析中发现每个表的数据遍历了很多(其实是全部),可以添加索引进行优化,同时可以看到a表extra有using temorary就是使用临时表,这是需要优化的。

这篇文章比较简单,主要讲了mysql的相关使用,等以后再sql优化有了更多的心得一定在总结。

原创粉丝点击