MySQL profiling剖析SQL

转自  https://www.cnblogs.com/xiaoboluo768/p/5157909.html5.1版本开始引入show profile剖析单条语句功能，支持show profiles和show profile语句，参数have_profiling;控制是否开启：查看是否支持这个功能（查询为yes表示支持）：mysql > show variables like 'have_profiling'; +----------------+-------+ | Variable_name  | Value | +----------------+-------+ | have_profiling | YES   | +----------------+-------+ 1 row in set (0.00 sec)  需要临时使用时直接sql命令行中输入：set profiling=1;来开启mysql> set profiling=1;Query OK, 0 rows affected, 1 warning (0.00 sec) 然后在服务器上执行SQL语句，都会被测量其消耗的时间和其他一些查询执行状态变更相关的数据mysql> select count(*) from xx;+----------+| count(*) |+----------+|   262144 |+----------+1 row in set (0.05 sec) 然后再执行：show prifiles;命令，所有的查询SQL都会被列出来mysql> show profiles;+----------+------------+-------------------------+| Query_ID | Duration   | Query                   |+----------+------------+-------------------------+|        1 | 0.05645950 | select count(*) from xx |+----------+------------+-------------------------+1 row in set, 1 warning (0.00 sec) 然后根据编号查询具体SQL的执行过程，这里演示只执行了一句，那就选项query id为1mysql> show profile for query 1;+----------------------+----------+| Status               | Duration |+----------------------+----------+| starting             | 0.000041 || checking permissions | 0.000004 || Opening tables       | 0.000017 || init                 | 0.000010 || System lock          | 0.000006 || optimizing           | 0.000004 || statistics           | 0.000009 || preparing            | 0.000008 || executing            | 0.000001 || Sending data         | 0.056110 || end                  | 0.000009 || query end            | 0.000007 || closing tables       | 0.000011 || freeing items        | 0.000121 || logging slow query   | 0.000001 || logging slow query   | 0.000093 || cleaning up          | 0.000010 |+----------------------+----------+17 rows in set, 1 warning (0.00 sec) 当查到最耗时的线程状态时，可以进一步选择all或者cpu,block io,page faults等明细类型来查看mysql在每个线程状态中使用什么资源上耗费了过高的时间：show profile cpu for query 2;  上面的输出中可以以很高的精度显示了查询的响应时间，列出了查询执行的每个步骤花费的时间，其结果很难确定哪个步骤花费的时间太多，因为输出是按照执行顺序排序，而不是按照花费大小来排序的，如果要按照花费大小排序，就不能使用show prifile命令，而是直接使用information_schema.profiling表。如：mysql> set profiling=1;Query OK, 0 rows affected, 1 warning (0.00 sec) mysql> select count(*) from xx;+----------+| count(*) |+----------+|   262144 |+----------+1 row in set (0.05 sec) mysql> show profiles;+----------+------------+-------------------------+| Query_ID | Duration   | Query                   |+----------+------------+-------------------------+|        1 | 0.05509950 | select count(*) from xx |+----------+------------+-------------------------+1 row in set, 1 warning (0.00 sec) mysql> set @query_id=1;Query OK, 0 rows affected (0.00 sec) mysql> select state,sum(duration) as total_r,round(100*sum(duration)/(select sum(duration) from information_schema.profiling where query_id=@query_id),2) as pct_r,count(*) as calls,sum(duration)/count(*) as "r/call" from information_schema.profiling where query_id=@query_id group by state order by total_r desc;+----------------------+----------+-------+-------+--------------+| state                | total_r  | pct_r | calls | r/call       |+----------------------+----------+-------+-------+--------------+| Sending data         | 0.054629 | 99.14 |     1 | 0.0546290000 || freeing items        | 0.000267 |  0.48 |     1 | 0.0002670000 || logging slow query   | 0.000070 |  0.13 |     2 | 0.0000350000 || starting             | 0.000040 |  0.07 |     1 | 0.0000400000 || Opening tables       | 0.000016 |  0.03 |     1 | 0.0000160000 || closing tables       | 0.000011 |  0.02 |     1 | 0.0000110000 || init                 | 0.000010 |  0.02 |     1 | 0.0000100000 || cleaning up          | 0.000010 |  0.02 |     1 | 0.0000100000 || end                  | 0.000009 |  0.02 |     1 | 0.0000090000 || statistics           | 0.000009 |  0.02 |     1 | 0.0000090000 || preparing            | 0.000008 |  0.01 |     1 | 0.0000080000 || query end            | 0.000007 |  0.01 |     1 | 0.0000070000 || System lock          | 0.000006 |  0.01 |     1 | 0.0000060000 || checking permissions | 0.000005 |  0.01 |     1 | 0.0000050000 || optimizing           | 0.000004 |  0.01 |     1 | 0.0000040000 || executing            | 0.000001 |  0.00 |     1 | 0.0000010000 |+----------------------+----------+-------+-------+--------------+16 rows in set (0.01 sec) 从上面的结果中可以看到，第一个是sending data（如果产生了临时表，第一就不是它了，那么临时表也是优先要解决的优化问题），另外还有sorting result（结果排序）也要注意，如果占比比较高，也要想办法优化，一般不建议在tuning sort buffer（优化排序缓冲区）或者类似的活动上花时间去优化。 如果要查询query id为1的Sending data状态的详细信息，可以使用如下SQL查询：select * from information_schema.profiling where query_id=1 and state='Sending data'\G; 最后，做完剖析测试别忘记 断开你的连接或者 set profiling=0 关闭这个功能。