1、性能优化简介
什么是性能？性能是完成某件任务所需要的时间度量，简而言之，性能即响应时间。这是一个非常重要的原则。在实际工作中，如果我们把性能优化看作是提升每秒的查询量，那么这其实只是吞吐量的优化，吞吐量的提升可以看做性能优化的副产品。所以，如果我们将降低响应时间看做是性能优化，那我们就需要理解为什么服务器执行查询会需要这么多时间，从而引出我们性能优化的第二个原则：无法测量就无法有效的优化。所以第一步应该测量时间花在哪里。
1.1 通过性能剖析进行优化
一旦掌握并实践面向响应实践的优化方法，就会发现需要不断的对系统进行性能剖析。性能剖析是测量和分析时间花费在哪里的主要方法。性能剖析一般有两个步骤：测量任务所花费的时间；然后对结果进行统计和排序，将重要的任务排到前面。
1.2 理解性能剖析
MySQL的性能剖析（profile）将最重要的任务展示在前面，但有时候没显示出来的信息也很重要。不幸的是，尽管性能剖析输出 了排名、 总计和平均值，但还是有很多需要的信息是缺失的，如下所示。
① 值得优化的查询（worthwhile query) :性能剖析不会自动给出哪些查询值得花时间去优化。
② 异常情况：某些任务即使没有出现在性能剖析输出的前面也需要优化。
③ 未知的未知：一款好的性能剖析工具会显示可能的 “丢失的时间”。
④ 被掩藏的细节：性能剖析无撞显示所有响应时间的分布。
2、对应用程序进行性能剖析
对任何需要消耗时间的任务都可以做性能剖析， 当然也包括应用程序。实际上， 剖析应用程序一般比剖析数据库服务器容易， 而且回报更多。这里我们推荐一个好的应用工具--New Relic，New Relic 会插入到应用程序中进行性能剖析， 将收集到的数据发送到一个基于Web的 仪表盘， 使用仪表盘可以更容易利用面向响应时间的方怯分析应用性能。 这样用户只需 要考虑做那些正确的事情， 而不用考虑如何去做。 而且New Relic测量了很多用户体验相关的点， 涵盖从Web浏览器到应用代码， 再到数据库及其他外部调用。
3、剖析mysql查询
对查询进行性能剖析有两种方式，每种方式都有各自的问题。可以剖析整个数据库服务器，这样可以分析出哪些查询是主要的压力来源。定位到具体需要优化的查询后，也可以钻取下去对这些查询进行单独的剖析，分析哪些子任务是响应时间的主要消耗者。
3.1 剖析服务器负载
服务器端的剖析很有价值，因为在服务器端可以有效地审计效率低下的查询。定位和优化“坏”查询能够显著地提升应用的性能，也能解决某些特定的难题，还可以降低服务器的整体压力。
捕获mysql的查询到日志中：第一种是通过--processlist 选项不断查看SHOW FULL PROCESSLIST的输出， 记录查询第 一次出现的时间和消失的时间。 某些情况下这样的精度也足够发现问题， 但却无战捕获所有的查询。第二种技术是通过抓取TCP网络包， 然后根据MySQL的客户端／服务端通信协议进行解析。
分析查询日志：强烈建议大家从现在起就利用慢查询日志捕获服务器上的所有查询， 并且进行分析。 不要直接打开整个慢查询日志进行分析， 这样做只会浪费时间和金钱。 首先应该生成一个剖析报告， 如果需要， 则可以再查看日志中需要特别关注的部分。 自顶向下是比较好 的方式， 否则有可能像前面提到的， 反而导致业务的逆优化。这里我们推荐使用pt-query-digest。
3.2 剖析单条查询
在定位到需要优化的单条查询之后，可以针对次查询钻探更多的信息。确认为什么会花费这么长的时间执行，以及需要如何去优化。
使用show profile；使用show status；使用慢查询日志；使用performance schema；
总结：
1、我们认为定义性能最有效的方越是晌应时间。
2、如果无法测量就无陆有效地优化， 所以性能优化工作需要基于高质量、 全方位及完整的响应时间测量。
3、测量的最佳开始点是应用程序， 而不是数据库。 即使问题出在底层的数据库， 借助良好的测量也可以很容易地发现问题。4、完整的测量会产生大量需要分析的数据， 所以需要用到剖析器。 这是最佳的工具，可以帮助将重要的问题冒泡到前面， 这样就可以决定从哪里开始分析会比较好。
5、优化和提升是两回事。 当继续提升的成本超过收益的时候， 应当停止优化。