在我们的技术咨询生涯中，最常碰到的三个性能相关的服务请求是:如何确认美国服务器是否达到了性能最佳的状态、找出某条语句为什么执行不够快，以及诊断被用户描述成“停顿”、“堆积”或者“卡死”的某些间歇性疑难故障。本章将主要针对这三个问题做出解答。我们将提供一些工具和技巧来优化整机的性能、优化单条语句的执行速度，以及诊断或者解决那些很难观察到的问题(这些问题用户往往很难知道其根源，有时候甚至都很难察觉到它的存在)。

这看起来是个艰巨的任务，但是事实证明，有一个简单的方法能够从噪声中发现苗头。这个方法就是专注于测量美国服务器的时间花费在哪里，使用的技术则是性能剖析(profiling).在本章，我们将展示如何测量系统并生成剖析报告，以及如何分析系统的整个堆栈(stack), 包括从应用程序到数据库美国服务器到单个查询。

首先我们要保持空杯精神，抛弃掉- 些关于性能的常见的误解。这有一定的难度，下面我们一起通过一些例子来说明问题在哪里。

性能优化简介

问10个人关于性能的问题，可能会得到10个不同的回答，比如“每秒查询次数”、"CPU利用率”、“可扩展性”之类。这其实也没有问题，每个人在不同场景下对性能有不同的理解，但本章将给性能一个正式的定义。我们将性能定义为完成某件任务所需要的时间度量，换句话说，性能即响应时间，这是一个非常重要的原则。我们通过任务和时间而不是资源来测量性能。数据库美国服务器的目的是执行SQL语句，所以它关注的任务是查询或者语句，如SELECT, UPDATE, DELETE 等作。数据库美国服务器的性能用查询的响应时间来度量，单位是每个查询花费的时间。

还有另外一个问题:什么是优化?我们暂时不讨论这个问题，而是假设性能优化就是在一定的工作负载下尽可能地降低响应。很多人对此很迷茫。假如你认为性能优化是降低CPU利用率，那么可以减少对资源的使用。但这是一个陷阱，资源是用来消耗并用来工作的，所以有时候消耗更多的资源能够加快查询速度。很多时候将使用老版本InoDB引擎的MysSQL升级到新版本后，CPU利用率会上升得很厉害，这并不代表性能出现了问题，反而说明新版本的InnoDB对资源的利用率上升了。查询的响应时间则更能体现升级后的性能是不是变得更好。版本升级有时候会带来一此bug.比如不能利用某些索引从而导致CPU利用率上升。CPU利用率只是一种现象， 而不是很好的可度量的目标。

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

所以如果目标是降低响应时间，那么就需要理解为什么美国服务器执行查询需要这么多时间，然后去减少或者消除那些对获得查询结果来说不必要的工作。也就是说，先要搞清楚时间花在哪里。这就引申出优化的第二个原则:无法测量就无法有效地优化。所以第一步应该测量时间花在什么地方。

我们观察到，很多人在优化时，都将精力放在修改些东东西上，却很少去进行精确的测量。我们的做法完全相反，将花费非常多，甚至90%的时间来测量响应时间花在哪里。如果通过测量没有找到答案，那要么是测量的方式错了，要么是测量得不够完整。如果测量了系统中完整而且正确的数据，性能问题一般都能暴露出来，对症下药的解决方案也就比较明了。测量是项很有挑战性的工作， 并且分析结果也同样有挑战性，测出时间花在哪里，和知道为什么花在那里，是两码事。

前面提到需要合适的测量范围，这是什么意思呢?合适的测量范围是说只测量需要优化的活动。有两种比较常见的情况会导致不合适的测量：

(1)在错误的时间启动和停止测量。

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

例如，一个常见的错误是先查看慢查询，然后又去排查整个美国服务器的情况来判断问题在哪里。如果确认有慢查询，那么就应该测量慢查询，而不是测量整个美国服务器。测量的应该是从慢查询的开始到结束的时间，而不是查询之前或查询之后的时间。

完成一项任务所需要的时间可以分成两部分:执行时间和等待时间。如果要优化任务的执行时间，最好的办法是通过测量定位不同的子任务花费的时间，然后优化去掉一些子任务、降低子任务的执行频率或者提升子任务的效率。而优化任务的等待时间则相对要复杂一些，因为等待有可能是由其他系统间接影响导致，任务之间也可能由于争用磁盘或者CPU资源而相互影响。根据时间是花在执行还是等待上的不同，诊断也需要不同的工具和技术。