如何确认服务器是否达到了性能最佳的状态、找出某条语句为什么执行不够快，以及诊断被用户描述成停顿、堆积、卡死的故障。
3.1 性能优化简介
性能：为完成某件任务所需的时间度量，换句话说即响应时间。
作者花90%以上的时间在测量响应时间花在哪里，如果没有找到正确的答案，就是测量方式错了。
有的人优化cpi利用率、优化每秒查询量（吞吐量优化），这些都可以说是副产品。
3.1.1 通过性能剖析进行优化
性能剖析（profiling）是测量和分析时间花费在哪里的主要方法，一般两个步骤：测量任务所花费时间、对结果进行统计和排序，把重要的任务排到前面
3.1.2 理解性能剖析
值得优化的查询：如果一个占总响应时间不超过5%的查询时不太值得优化的。
异常情况：但是有些任务执行次数少，但每次很慢，所以占总相应时间比不突出。
未知的未知：一款好的性能剖析工具会显示可能的丢失的时间。
被掩藏的细节：无法显示所有响应时间的分布，只相信平均值是非常危险的。
3.2 对应用程序进行性能剖析
剖析应用比剖析数据库容易，而且收获更多。
性能瓶颈有很多影响因素：
- 外部资源，调用了外部的web服务或者搜索引擎
- 需要处理大量的数据
- 循环执行昂贵的操作，比如正则表达式
- 使用了低效的算法
现在已经有很多工具可以帮助我们剖析了如New Relic，就是全天候地测量生产环境代码。
3.2.1 测量php应用程序
xphrof
3.3 剖析MySQL查询
3.3.1 剖析服务器负载
捕获mySQL的查询到日志文件中。
3.3.2 剖析单条查询
SHOW PROFILES;可以查看某次查询的结果
使用SHOW STATUS返回了一些计数器，既有全局计数器，也有某个链接的会话级别的计数器。
https://lxneng.iteye.com/blog/451985
http://www.ttlsa.com/mysql/mysql_show_status_descriptsions/
使用慢查询日志
http://www.cnblogs.com/kerrycode/p/5593204.html
https://www.cnblogs.com/luyucheng/p/6265594.html
使用Performance Schema
3.3.3 使用性能剖析
3.4 诊断间歇性问题
间歇性的问题比如系统偶尔停顿或者慢查询，难以浮现的问题有以下案例
- 应用通过curl从一个运行的很慢的外部服务器获取数据
- memcached缓存中的一些重要条目过期导致mysql重新生成
- dns查询偶尔超时
- 互斥锁争用或者内部查询缓存的算法效率太低的缘故，mysql的查询缓存有时候会导致服务器短暂停顿。
- 并发超过阈值时，innodb的扩展性质导致查询计划优化。
3.4.1 单条查询问题还是服务器问题
如何判断是单条查询问题还是服务器问题呢？如果问题周期性出现，我们可以这样分析：
1、使用show global status。
2、使用SHOW PROCESSLIST
3、使用查询日志发现问题，设置long_query_time 为0
可视化来理解发现的问题。
3.4.2 捕获诊断数据
诊断触发器
收集数据、解释结果。
3.5 其他剖析工具
3.5.1 使用USER_STATICS 表
3.5.2 使用strace
3.6 总结
没有经历的人看这一章，真的是很费劲。
这一章更多的是道的层面，正如总结的结果：
