profiling中要关注哪些信息

最后更新于:2022-04-01 21:02:42

利用MySQL的PROFILE功能,我们可以很方便的查看一个SQL具体的执行代价是怎样的,尤其是可以分析它的最大瓶颈在哪里。目前PROFILE功能可提供除了内存以外的其他资源消耗统计,例如CPU、I/O、CONTEXT、SWAP等。 PROFILE功能只能在SESSION级别使用,还做不到像SQL Server那样可以全局开启,收集一段时间后再关闭,这点有待改进。关于PROFILE的具体用法大家可以查看手册 [13.7.5.31 SHOW PROFILE Syntax](http://dev.mysql.com/doc/refman/5.6/en/show-profile.html),这里不细说。 大部分情况下,PROFILE的结果我们主要关注两列:Status、Duration,前者表示的是PROFILE里的状态,它和PROCESSLIST的状态基本是一致的,后者是该状态的耗时。因此,我们最主要的是关注处于哪个状态耗时最久,这些状态中,哪些可以进一步优化。 和我们之前的一个分享 [[MySQL FAQ]系列 — processlist中哪些状态要引起关注](http://imysql.com/2015/06/10/mysql-faq-processlist-thread-states.shtml "编辑“[MySQL FAQ]系列 — processlist中哪些状态要引起关注”") 类似,PROFILE中,下面几种状态是要尤其关注的,而且大多数通过创建合适的索引就可以完成优化。 | Status | 建议 | |------|--------| | System lock | 确认是由于哪个锁引起的,通常是因为MySQL或InnoDB内核级的锁引起的建议:如果耗时较大再关注即可,一般情况下都还好 | | Sending data | 从server端发送数据到客户端,也有可能是接收存储引擎层返回的数据,再发送给客户端,数据量很大时尤其经常能看见(备注:Sending Data不是网络发送,是从硬盘读取,发送到网络是Writing to net 建议:通过索引或加上LIMIT,减少需要扫描并且发送给客户端的数据量) | | Sorting result | 正在对结果进行排序,类似Creating sort index,不过是正常表,而不是在内存表中进行排序(建议:创建适当的索引) | | Table lock | 表级锁,没什么好说的,要么是因为MyISAM引擎表级锁,要么是其他情况显式锁表 | | create sort index | 当前的SELECT中需要用到临时表在进行ORDER BY排序(建议:创建适当的索引) | | checking query cache for querychecking privileges on cachedsending cached result to clien storing result in query cache | 和query cache相关的状态,已经多次强烈建议关闭 | 更多状态请移步之前的分享文章 [[MySQL FAQ]系列 — processlist中哪些状态要引起关注](http://imysql.com/2015/06/10/mysql-faq-processlist-thread-states.shtml "编辑“[MySQL FAQ]系列 — processlist中哪些状态要引起关注”") 以及官方文档 [8.14.2 General Thread States](http://dev.mysql.com/doc/refman/5.6/en/general-thread-states.html),如果有未涉及想了解的状态,也请在评论区给我留言,谢谢。
';