ITPub博客

首页 > 数据库 > MySQL > MySQL profiling剖析SQL

MySQL profiling剖析SQL

MySQL 作者:guocun09 时间:2020-12-09 19:28:12 0 删除 编辑

转自  https://www.cnblogs.com/xiaoboluo768/p/5157909.html

5.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为1

mysql> 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 关闭这个功能。


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/25583515/viewspace-2740845/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
DBA,掌握Oracle,SQLServer,MySQL,hadoop,casscandra等数据库。喜爱深入研究数据库技术原理,擅长管理和优化工作。

注册时间:2011-10-02

  • 博文量
    164
  • 访问量
    593959