性能优化简介

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

假如你任务性感优化 是降低CPU利用率，那么可以减少对资源的使用。但这是一个陷阱，资源是用来消耗并用来工作的，所以有时候消耗更多的资源能够加快查询速度。很多时候将使用老版本InnoDB引擎的MySQL升级到新版本后，CPU利用率会上升的很厉害，这并不代表性能出现了问题，反而说明新版本的InnoDB对资源的利用率上升了，查询的响应时间则更能体现升级后的性能是不是变得更好。版本升级有时候会带来一下bug，比如不能利用某些索引而导致CPU利用率上升。CPU利用率只是一个现象，而不是很好的可度量的目标。

同样，如果把性能优化仅仅看成是提升每秒查询量，这其实只是吞吐量优化。吞吐量的提升可以看做性能优化的副产品。对查询的优化可以让服务器每秒执行更多的查询，因为每条查询执行的时间更短了（吞吐量的定义是单位时间内的查询数量，这正好是我们对性能的定义的倒数）。

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

很多人在优化时，都将精力放在修改一下东西上，却很少去进行精确的测量。

我们应该将花费非常多甚至90%的时间来测量响应时间花在哪里。如果通过测量没有找到答案，那要么是测量的方式错了，要么是测量的不够完整。如果测量了系统中完整而且正确的数据，性能问题一般都会暴露出来，对症下药的解决方案也就比较明了。测量是一项很有挑战性的工作，并且分析结果也同样有挑战性，测出时间花在哪里，和制度为什么花在那里，是两码事。

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

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

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

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

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