三、服务器性能剖析
最常碰到的三个性能相关的服务请求是：如何确认服务器是否达到了性能最佳的状态、找出某条语句为什么执行不够快，以及诊断被用户描述成 "停顿"、"堆积" 或者 "卡死" 的某些间歇性疑难故障。
3.1 性能优化简介
我们将性能定义为完成某件任务所需要的时间度量。换句话说，性能即响应时间。这是一个非常重要的原则，我们通过任务和时间而不是资源来测量性能。
什么是优化？暂时不考虑这个问题，而是假设性能优化就是在一定的工作负载下尽可能地降低响应时间。
完成一项任务所需的时间可以分成两部分：执行时间和等待时间。如果要优化任务的执行时间，最好的办法是通过测量定位不同的子任务花费的时间，然后优化去掉一些子任务、降低子任务的执行频率或者提升子任务的效率。而优化任务的等待时间则相对要复杂一些，因为等待有可能是由其他系统见解影响导致，任务之间也可能由于争用磁盘或者CPU资源而相互影响。根据时间是花在执行还是等待时间上的不同，诊断也需要不同的工具和技术。
1）通过性能剖析进行优化
性能剖析一般有两个步骤：测量任务所花费的时间；然后对结果进行统计和排序，将重要的任务排到前面，对相似的任务分组。
基于执行时间的分析和基于等待的分析。
基于执行时间的分析研究的是什么任务的执行时间最长，而基于等待的分析则是判断任务在什么地方被阻塞的时间最长。
3.2 对应用程序进行性能分析
性能瓶颈可能有很多影响因素：
- 外部资源，比如调用了外部的web服务或者搜索引擎
- 应用需要处理大量的数据
- 在循环中执行昂贵的操作
- 使用了低效的算法
3.3 剖析MySQL查询
慢查询日志 long_query_time
set profiling=1;
show profiles;
show status;
show global status;
show processlist\G;
show tables from information_schema like '%_statistics;'
3.6 总结
本章给出了一些基本的思路和技术，有助于你成功地进行性能优化。正确的思维方式是开启系统的全部潜力和应用本书其他章节提供的知识的关键。下面是我们试图演示的一些基本知识点：
- 我们认为定义性能最有效的方法是响应时间
- 如果无法测量就无法有效地优化，所以性能优化工作需要基于高质量、全方位及完整的响应时间测量
- 测量的最佳开始点是应用程序，而不是数据库。即使问题出在底层的数据库，借助良好的测量也可以很容易地发现问题。
- 大多数系统无法完整地测量，测量有时候也会有错误的结果。但也可以想办法绕过一些限制，并得到好的结果（但是要能意识到所使用的方法的缺陷和不确定性在哪里）
- 完整的测量会产生大量需要分析的数据，所以需要用到剖析器。这是最佳的工具，可以帮助将重要的问题冒泡岛前面，这样就可以决定从哪里开始分析会比较好
- 剖析报告是一种汇总信息，掩盖和丢弃了太多信息。而且它不会告诉你缺少了什么，所以完全依赖剖析报告也是不明智的
- 有两种消耗时间的操作：工作或者等待。大多数剖析器只能测量因为工作而消耗的时间，所以等待分析有时候是很有用的补充，尤其是当CPU利用率很低但工作却一直无法完成的时候。
- 优化和提升是两回事。当继续提升的成本超过收益的时候，应当停止优化。
- 注意你的直觉，但应该只根据直觉来指导解决问题的思路，而不是用于确定系统的问题。决策应当尽量基于数据而不是感觉。
总体来说，我们认为解决性能问题的方法，首先是要澄清问题，然后选择合适的技术来解答这些问题。如果你想尝试提升服务器的总提醒你，那么一个比较好的起点是将所有查询记录到日志中，然后利用 pt-query-digest 工具生成系统级别的剖析报告。如果是要追查某些性能低下，记录和剖析的方法也会有帮助。可以把精力放在寻找那些消耗时间最多的、导致了糟糕的用户体验的，或者那些高度变化的，抑或有奇怪的响应时间直方图的查询。当找到了这些 "坏" 查询时，要钻取pt-query-digest 报告中包含的该查询的详细信息，或者使用 SHOW PROFILE 及其他诸如 EXPLAIN 这样的工具。
如果找不到这些查询性能低下的原因，那么也可能是遇到了服务器级别的性能问题。这时，可以较高精度测量和绘制服务器状态计数器的细节信息。如果通过这样的分析重现了问题，则应该花费一点时间来确定可靠的触发条件，尽量避免漏检或者误报。如果已经可以捕获故障活动期间的数据，但还是无法找到其根本原因，则要么尝试捕获更多的数据，要么尝试寻求帮助。
我们无法完整地测量工作系统，但说到底它们都是某种状态机，所以只要足够细心，逻辑清晰并且坚持下去，通常来说都能得到想要的结果。要注意的是不要把原因和结果搞混了，而且在确认问题之前也不要随便针对系统做变动。
理论上纯粹的自顶向下的方法分析和详尽的测量只是理想的情况，而我们常常需要处理的是真实系统。真实系统是复杂且无法充分测量的，所以我们只能根据情况尽力而为。使用诸如 pt-query-digest 和 MySQL 企业监控器的查询分析器这样的工具并不完美，通常都不会给出问题根源的直接证据。但真的掌握了以后，已经足以完成大部分的优化诊断工作了。
