性能优化的简介
问10个人关于性能的问题，可能会得到10个不同的回答，比如每秒查询次数，CPU利用率，可扩展性之类的。这其实也没什么问题，每个人在不同的场景下对性能有不同的理解。我们将性能定义为完成牟建人物锁需要的时间度量，换句话说，性能及响应时间，这是一个非常重要的原则。我们通通过任务和时间而不是资源来测量性能。数据库服务器的目的是执行SQL语句，所以他关注的任务是查询或者语句，如SELECT,UPDATE,DELETE等。数据库服务器的性能用查询的响应时间来度量，单位是每个查询花费的时间。
还有另外一个问题；什么是优化？我们暂时不讨论这个问题，而是假设性能优化就是在一定的工作负载下尽可能低降低响应时间。
很多人对此很迷茫。假如你认为性能优化是降低CPU利用率，那么可以减少对资源的使用。但这是一个陷进，资源是用来消耗并用来工作的，所以有时候消耗更多的资源能够加快查询进度。很多时候将老版本的InnoDB引擎的MySQL升级到新版本后，CPU利用率上升的很厉害，这并不代表性能出现问题，反而说明新版本的InnoDB对资源的利用率上升。查询的响应时间则更能体现升级后的性能是不是变得更好，版本升级会带来一些BUG，比如不能利用某些索引从而导致CPU利用率上升。CPU利用率只是一种现象，而不是很好的可度量目标。
同样，如果性能优化仅仅看成是提升每秒查询量，这其实只是吞吐量优化，吞吐量的提升可以看做性能优化的副产品。对查询的优化可以让服务器每秒执行更多的查询，因为这条查询的执行的时间短了。
所以如果目标是降低响应时间，那么就需要理解为什么服务器执行查询需要这么多时间，然后去减少或者消除对获得查询结果来说不必要的工作。也就是说，先要搞清楚时间花在哪里。这就引申出优化的第二个原则；无法测量就无法有效的优化，多以第一步应该测量时间应该花在什么地方。
我们观察到很多人在优化时，都将精力放在修改一些东西上，却很少去进行精确的测量。我们的做法完全相反，将花费非常多，甚至是90%的时间来测量响应时间花在哪里。如果通过测量没有找到答案，那么要是测量的方式错了，要么史测量的方式不够完整，如果测量了系统中完整而且正确的数据，性能问题一般都能暴露出来。对症下药的解决方案也就是比较明了。测量是一项很有挑战性的工作，并且分析结果也同样有挑战性，测量时间话在哪里，和知道为什么花在哪里，是两码事。
