「高性能MySQL阅读笔记」第三章服务器性能剖析-CSDN博客

本文链接：https://blog.csdn.net/weixin_36642193/article/details/129877356

第三章服务器性能剖析

无法测量就无法优化。所以第一步应该测量时间花在什么地方

有两种比较常见的情况会导致不合适的测量：

在错误的时间启动和停止测量
测量的是聚合后的信息，而不是目标活动本身

3.1.1 通过性能剖析进行优化

性能剖析是测量和分析时间花费在哪里的主要方法。性能剖析一般有两个步骤：测量任务所花费的时间；然后对结果进行统计和排序，将重要的任务排到前面。

基于执行时间的分析
基于等待的分析

3.1.2 理解性能剖析

尽管性能剖析输出了排名、总计和平均值，但还是有很多需要的信息是缺失的：

值得优化的查询
- 一些只占总响应时间比重很小的查询是不值得优化的。根据阿姆达定律，对一个占总响应时间不超过5%的查询进行优化，无论如何努力收益也不会超过5%.
- 如果优化的成本大于收益，就应当停止优化
异常情况
- 某些任务即使没有出现在性能剖析输出的前面也需要优化
未知的未知
- 一款好的性能剖析工具会显示可能的“丢失的时间“。
被隐藏的细节
- 性能剖析无法显示所有响应时间的分布。

3.2 对应用程序进行性能剖析

性能瓶颈可能有很多影响因素：

外部资源，比如：调用了外部的web服务或者搜索引擎
应用需要处理大量的数据，比如：分析一个超大的XML文件
在循环中执行昂贵的操作，比如：滥用正则表达式
使用了低效率的算法，比如：使用暴力搜索算法（native search algorithm）来查找列表中的项

3.3 剖析MySQL查询

3.3.1 剖析服务器负载

捕获MySQL的查询到日志文件中
分析查询日志

3.3.2 剖析单条查询

使用PROFILS命令

mysql>set profiling = 1;
mysql>select * from user;

在这里插入图片描述

mysql>SHOW PROFILE FOR QUERY 9;

在这里插入图片描述

使用INFOMATION_SCHEMA

select
	state ,
	sum(duration) as total_R,
	ROUND( 100 * sum(duration) / (select SUM(duration) from information_schema.PROFILING p where query_id = 55), 2) as Pct_R,
	count(*) as Calls,
	SUM(duration) / count(*) as "R/Call"
from
	information_schema.PROFILING
where
	QUERY_ID = 55
GROUP by
	STATE
order by
	total_R desc;

在这里插入图片描述