mysql如何优化一条慢sql_MySQL慢SQL优化-如何分析性能瓶颈

优化慢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,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 |

+----------+------------+------------------------------------------------------------------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------------------------------------------------------------+

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优化有了更多的心得一定在总结。

PS

关于join的优化

在没有分库分表的时候，join在建立合适的索引后还是可用的。

关于join的原理 嵌套循环算法，通过join链接的字段一般要建立索义。

看过嵌套循环算法后，其实A left B和B left A在算法复杂度上没有区别，所以还是根据业务选择即可。

同时，嵌套循环的数据并不一定是全表数据，如果where中约束其中一个表，假设是B，这时在循环遍历B表是遍历where约束的数据量，所以并不是全量对比。