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