第三章-服务器性能剖析

——「高性能MYSQL」读书笔记（第三章）

《高性能****MYSQL》

MYSQL经典书籍，常读常新。

最常碰到的三个性能相关的服务请求是：

如何确认服务器是否达到性能的最佳状态

找出某条语句为什么执行不够快

诊断被用户描述成停顿，堆积或者卡死的间歇性疑难故障

这看起来是一个艰巨的任务，但是有一种很简单的方法就是专注于测量服务器的时间花费在哪里，使用的技术就是性能剖析

性能的定义：完成某件任务所需要的时间度量。

原则1：性能就是****响应时间

所以我们通过任务和时间而不是资源来测量性能。

那么什么是优化？首先假设性能优化就是在一定的工作负荷下尽可能地降低响应时间

假如你认为性能优化是降低CPU利用率，那么可以减少对资源的使用，这是一个陷阱，资源是用来消耗并用来工作的，有时候消耗更多地资源反而能够加快查询效率

同样的，如果把性能优化仅仅看成是提升每秒的查询量，这其实只是吞吐量优化，吞吐量可以看作是性能的副产品

所以目标如果是响应时间的降低的话，先要搞清楚时间花在哪里，这就要引出

原则2：无法测量就无法有效地优化

不合适的测量：

在错误的时间启动和停止测量

测量的是聚合后的信息，而不是目标活动本身

完成一项任务所需要的时间可以分成两部分：执行时间和等待时间

优化执行时间：通过测量定位不同的子任务花费的时间，然后优化去掉一些子任务，降低子任务的执行频率或者提升子任务的效率

优化等待时间：复杂，因为等待有可能是由其他系统间接影响导致的

那么如何判断测量是否正确呢？

实际上，测量基本上都是错误的，所以这个问题应该是测量到底有多么不准确

性能剖析的步骤：

测量任务所花费的时间，用结束时间减去启动时间得到响应时间

然后对结果进行统计和排序，将重要的任务排到前面

实际上分析MySQL一般指的都是查询，如果任务执行时间长是因为消耗了太多的资源且大部分时间花费在执行上，这时对等待的分析作用就不大，反之亦然。

理想的性能优化技术依赖于更多的测量点，即使系统没有提供测量点，还以从外部去测量系统

性能剖析本身会导致服务器变慢吗？

是的：是因为性能刨析确实会导致应用慢一些

不是：是因为性能刨析可以帮助应用运行得更快

这说法不是很矛盾吗？为什么会这么说，因为性能剖析和定期检测都会带来额外开销，关键就在于收益能否抵消这部分开销

剖析服务器负载

在服务器端可以有效地审计效率低下的查询，定位和优化坏查询能够显著地提升应用的性能。

降低服务器的负载也可以推迟或者避免升级更昂贵的需求，还可以发现和定位用户体验。

有一个工具可以帮助到我们，就是慢查询日志

慢查询日志

开销最低，精度最高的测量查询时间的工具，响应时间可以达到微秒级

通用日志

通用日志在请求到服务器时进行记录，所以不包含响应时间和执行计划等重要信息

剖析单条查询

使用SHOW PROFILE：唯一一个在GA版本中包含真正的查询剖析工具，默认是禁用的。这个工具最有用的作用还是在语句执行期间剖析服务器的具体工作

使用SHOW STATUS：返回了一些计数器，可以显示某些活动如度索引的频繁程度，但无法给出消耗了多少时间。

诊断间隙性问题

单条查询问题还是服务器问题？

如果服务器整体运行没有问题，只有某条查询偶尔变慢，就需要将注意力放到这条特定的查询上面

解决手段

使用SHOW GLOBAL STATUS：这个方法实际上就是以较高频率比如一秒执行一次SHOW GLOBAL STATUS命令捕获数据

使用SHOW PROCESSLIST：这个方法就是通过观察是否有大量线程处于不正常状态或者有其他不正常的特征

通过查询日志：需要开启慢查询日志并在全局级别设置long_query_time为0、并且要确认所有的连接都使用了新的设置