这里写目录标题
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 表结构
| X | X | X |
|---|---|---|
| 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 能从更宏观的角度去发现问题, 提供信息, 算是个很不错的分析工具。

411

被折叠的 条评论
为什么被折叠?



