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