总结
本章给出了一些基本的思路和技术有肋于你成功地进行性能优化正确的思维方式是开启系统的全部潜力和应用本书其他章节提供的知识的关键下面是我们试图演示的一些基本知识点
我们认为定义性能最有效的方法是响应时间
如果无法测量就无法有效地优化所以性能优化工作需要基于高质量全方位及完整的响应时间测量
测量的最佳开始点是应用程序而不是数据库即使问题出在底层的数据库借助良好的测量也可以很容易地发现问题
大多数系统无法完整地测量测量有时候也会有错误的结果但也可以想办法绕过一些限制并得到好的结果（但是要能意识到所使用的方法的缺陷和不确定性在哪里）
完整的测量会产生大量需要分析的数据所以需要用到剖析器这是最佳的工具可以帮助将重要的问题冒泡到前面这样就可以决定从哪里开始分析会比较好
剖析报告是一种汇总信息掩盖和丢弃了太多细节而且它不会告诉你缺少了什么所以完全依赖剖析报告也是不明智的
有两种消耗时间的操作工作或者等待大多数剖析器只能测量因为工作而消耗的时间所以等待分析有时候是很有用的补充尤其是当CPU 利用率很低但工作却一直无法完成的时候
优化和提升是两回事当继续提升的成本超过收益的时候应当停止优化
注意你的直觉但应该只根据直觉来指导解决问题的思路而不是用于确定系统的问题决策应当尽量基于数据而不是感觉
总体来说我们认为解决性能问题的方法首先是要澄清问题然后选择合适的技术来解答这些问题如果你想尝试提升服务器的总体性能那么一个比较好的起点是将所有查询记录到日志中然后利用ptquerydigest 工具生成系统级别的剖析报告如果是要追查某些性能低下的查询记录和剖析的方法也会有帮助可以把精力放在寻找那些消耗时间最多的导致了糟糕的用户体验的或者那些高度变化的抑或有奇怪的响应时间直方图的查询当找到了这些坏查询时要钻取ptquerydigest 报告中包含的该查询的详细信息或者使用SHOW PROFILE 及其他诸如EXPLAIN 这样的工具
如果找不到这些查询性能低下的原因那么也可能是遇到了服务器级别的性能问题这时可以较高精度测量和绘制服务器状态计数器的细节信息如果通过这样的分析重现了问题则应该通过同样的数据制定一个可靠的触发条件来收集更多的诊断数据多花费一点时间来确定可靠的触发条件尽量避免漏检或者误报如果已经可以捕获故障活动期间的数据但还是无法找到其根本原因则要么尝试捕获更多的数据要么尝试寻求帮助
我们无法完整地测量工作系统但说到底它们都是某种状态机所以只要足够细心逻辑清晰并且坚持下去通常来说都能得到想要的结果要注意的是不要把原因和结果搞混了而且在确认问题之前也不要随便针对系统做变动
理论上纯粹的自顶向下的方法分析和详尽的测量只是理想的情况而我们常常需要处理的是真实系统真实系统是复杂且无法充分测量的所以我们只能根据情况尽力而为使用诸如ptquerydigest 和MySQL 企业监控器的查询分析器这样的工具并不完美通常都不会给出问题根源的直接证据但真的掌握了以后已经足以完成大部分的优化诊断工作了
返回目录高性能MySQL
编辑推荐
ASPNET MVC 框架揭秘
Oracle索引技术
ASP NET开发培训视频教程
数据仓库与数据挖掘培训视频教程
