MySQL中提供了内置的性能分析工具profiling,今天就一起看下这个工具怎么使用.
首先确认profiling工具状态
查看profiling相关变量:开关及存储记录数
show VARIABLES like 'profil%'-------------------------------profiling ONprofiling_history_size 15
为了方便测试,先将存储记录调为100
set profiling_history_size = 100;
准备一条测试SQL
在test库下,自定义uu表,执行查询SQL,分析执行情况.
SELECT _rowid,u.*from test.uu u;
查看SQL ID
查看最近执行的SQL,可以发现该SQL的queryid是61,
show profiles;
执行sql,分析各阶段执行情况.
show profile for query 61;
可以发现该SQL执行时间最长的executing阶段.
因为该sql是简单查询,表中数据又很少,分析结果也是符合实际情况的.
不过showprofile是一个即将被废弃掉的命令,
官方已经推荐使用performance_schema.profiling表来查看SQL执行情况了.
performance_schema.profiling表结构1QUERY_ID查询ID, 用于标记不同的查询
2SEQ一个查询内部执行的步骤 , 从2开始
3STATE步骤的状态
4DURATION持续时间(单位: 秒)
5CPU_USER用户空间的cpu使用量
6CPU_SYSTEM内核空间的cpu使用量
7CONTEXT_VOLUNTARY上下文主动切换
8CONTEXT_INVOLUNTARY上下文被动切换
9BLOCK_OPS_IN阻塞输入操作
10BLOCK_OPS_OUT阻塞输出操作
11MESSAGES_SENT消息发送
12MESSAGES_RECEIVED消息接受
13PAGE_FAULTS_MAJOR主分页错误
14PAGE_FAULTS_MINOR次分页错误
15SWAPSswap次数
16SOURCE_FUNCTIONMySQL源码函数
17SOURCE_FILE源码文件
18SOURCE_LINE源码行数
通过profiling表,分析SQL执行情况:SELECT * from information_schema.profiling where query_id = 61;
可以发现执行时间是一样的,同时还增加了更多的信息.需要注意的是Sending data状态并不是单纯的发送数据,而是包括收集,发送数据两个阶段.这里列出来的state并不是所有状态,比如用到临时表时,还会有Creating tmp table等状态.上述例子openingtable占用时间最长,但这只限于当前情况,在不同的情况下,占用时间是不同的,所以一定要根据实际情况分析,不能一概而论.有观点认为这是个鸡肋的工具,并不能提供很好的解决方案.我想, profiling能从更宏观的角度去发现问题,提供信息,算是个很不错的分析工具.