3.1 性能优化简介
性能
性能的定义：为完成某件任务所需要的时间度量。即响应时间。
优化
测量和优化
无法测量就无法有效地优化。第一步应该测量时间花费在什么地方。
花费大量的时间测量是应该做的事，而不是一上来就做修改。
确定测量范围
确定合适的测量范围，只测量需要优化的活动。
例如，如果确认有慢查询，就应该侧慢查询，而不是测量整个服务器。测量应该是从慢查询的开始到结束的时间，而不是查询之前或查询之后的时间。
测量任务的执行时间和等待时间
完成一项任务所需要的时间可以分成两部分：执行时间和等待时间。
优化任务的执行时间，最好的办法是通过测量定位不同的子任务花费的时间，然后优化去掉一些子任务、降低子任务的执行频率或者提升子任务的效率。
定位和优化子任务时，需要注意，一些运行不频繁或者很短的子任务对整体响应时间的影响很小。如何确认哪些子任务是优化的目标呢？答案就是性能剖析，接下来将介绍通过性能剖析进行优化。
优化任务的等待时间相对复杂，因为等待时间可能是由其他系统间接影响导致，任务之间也可能由于争用磁盘或者CPU资源而相互影响。
如何判断测量是正确的？
实际上，这个问题的准确提法是：测量到底有多么不准确？要意识到使用的是测量数据，而不是其代表的实际数据。
3.1.1 通过性能剖析进行优化
一旦掌握并实践面向响应时间的优化方法，就会发现需要不断地对系统进行性能剖析（profiling）。
性能剖析一般有两个步骤：测量任务花费的时间；然后对结果进行统计和排序，将重要的任务排到前面。
我们将实际地讨论两种类型的性能剖析：基于执行时间的分析和基于等待的分析。
基于执行时间的分析研究的是什么任务的执行时间最长，而基于等待的分析则是判断任务在什么地方被阻塞的时间最长。
3.1.2 理解性能剖析
3.2 对应用程序进行性能剖析
3.3 剖析MySQL查询
3.3.1 剖析服务器负载
3.3.2 剖析单条查询
3.3.3 使用性能剖析
3.4 诊断间歇性问题
3.4.1 单条查询问题还是服务器问题
3.4.2 捕获诊断数据
3.4.3 一个诊断案例
3.5 其他剖析工具
3.5.1 使用user_statistics表
3.5.2 使用strace
3.6 总结
- 定义性能最有效的方法是响应时间
- 如果无法测量就无法优化，所以性能优化工作需要基于高质量、全方位及完整的响应时间测量。
- 测量的最佳开始点是应用程序，而不是数据库。即使问题出在底层的数据库，借助良好的测量也可以很容易地发现问题。
- 大多数系统无法完整地测量，测量有时候也会有错误的结果。但也可以想办法绕过一些限制，并得到好的结果。
- 完整的测量需要借助剖析器。
- 剖析报告是一种汇总信息，不要完全依赖。
- 有两种消耗时间的操作：工作或者等待。大多数剖析器只能测量因为工作而消耗的时间，所以等待分析有时候是很有用的补充，尤其是当CPU利用率很低但工作却一直无法完成的时候。
- 优化和提升是两回事。当继续提升的成本超过收益的时候，应当停止优化。
- 注意你的直觉，但应该只根据直觉来指导解决问题的思路，而不是用于确定系统的问题。决策应当尽量基于数据而不是感觉。
总体来说，我们认为解决性能问题的方法，首先是要澄清问题，然后选择合适的技术来解答这些问题。
如果想尝试提升服务器的总体性能，那么一个比较好的起点是将所有的查询记录到日志中，然后利用pt-query-digest工具生成系统级别的剖析报告。
可以把精力放在寻找那些消耗时间最多的、导致了糟糕的用户体验的，或者那些高度变化的，抑或有奇怪的响应时间直方图的查询。
如果找不到这些查询性能低下的原因，那么也可能遇到了服务器级别的性能问题。换句话说，我们需要重新站在更高的角度看待整个系统，从头重新思考，看看遗漏了什么。
我们无法完整地测量系统，但说到底它们都是某种状态机，所以只要足够细心，逻辑清晰并坚持下去，通常来说都能得到想要的结果。
要注意的是不要把原因和结果搞混了，而且在确认问题之前也不要随便针对系统做变动。工具虽然不完美，但是真多掌握了以后，已经足以完成大部分的优化诊断工作了。
Time waits for no one.