毛概第一章到第四章心得总结 高性能MySQL：第三章总结

高性能MySQL：第三章总结  

　　总结

　　本章给出了一些基本的思路和技术 有肋于你成功地进行性能优化 正确的思维方式是开启系统的全部潜力和应用本书其他章节提供的知识的关键 下面是我们试图演示的一些基本知识点

　　我们认为定义性能最有效的方法是响应时间

　　如果无法测量就无法有效地优化 所以性能优化工作需要基于高质量 全方位及完整的响应时间测量

　　测量的最佳开始点是应用程序 而不是数据库 即使问题出在底层的数据库 借助良好的测量也可以很容易地发现问题

　　大多数系统无法完整地测量 测量有时候也会有错误的结果 但也可以想办法绕过一些限制 并得到好的结果（但是要能意识到所使用的方法的缺陷和不确定性在哪里）

　　完整的测量会产生大量需要分析的数据 所以需要用到剖析器 这是最佳的工具 可以帮助将重要的问题冒泡到前面 这样就可以决定从哪里开始分析会比较好

　　剖析报告是一种汇总信息 掩盖和丢弃了太多细节 而且它不会告诉你缺少了什么 所以完全依赖剖析报告也是不明智的

　　有两种消耗时间的操作 工作或者等待 大多数剖析器只能测量因为工作而消耗的时间 所以等待分析有时候是很有用的补充 尤其是当CPU 利用率很低但工作却一直无法完成的时候

　　优化和提升是两回事 当继续提升的成本超过收益的时候 应当停止优化

　　注意你的直觉 但应该只根据直觉来指导解决问题的思路 而不是用于确定系统的问题 决策应当尽量基于数据而不是感觉

　　总体来说 我们认为解决性能问题的方法 首先是要澄清问题 然后选择合适的技术来解答这些问题 如果你想尝试提升服务器的总体性能 那么一个比较好的起点是将所有查询记录到日志中 然后利用pt query digest 工具生成系统级别的剖析报告 如果是要追查某些性能低下的查询 记录和剖析的方法也会有帮助 可以把精力放在寻找那些消耗时间最多的 导致了糟糕的用户体验的 或者那些高度变化的 抑或有奇怪的响应时间直方图的查询 当找到了这些 坏 查询时 要钻取pt query digest 报告中包含的该查询的详细信息 或者使用SHOW PROFILE 及其他诸如EXPLAIN 这样的工具

　　如果找不到这些查询性能低下的原因 那么也可能是遇到了服务器级别的性能问题 这时 可以较高精度测量和绘制服务器状态计数器的细节信息 如果通过这样的分析重现了问题 则应该通过同样的数据制定一个可靠的触发条件 来收集更多的诊断数据 多花费一点时间来确定可靠的触发条件 尽量避免漏检或者误报 如果已经可以捕获故障活动期间的数据 但还是无法找到其根本原因 则要么尝试捕获更多的数据 要么尝试寻求帮助

　　我们无法完整地测量工作系统 但说到底它们都是某种状态机 所以只要足够细心 逻辑清晰并且坚持下去 通常来说都能得到想要的结果 要注意的是不要把原因和结果搞混了 而且在确认问题之前也不要随便针对系统做变动

　　理论上纯粹的自顶向下的方法分析和详尽的测量只是理想的情况 而我们常常需要处理的是真实系统 真实系统是复杂且无法充分测量的 所以我们只能根据情况尽力而为 使用诸如pt query digest 和MySQL 企业监控器的查询分析器这样的工具并不完美 通常都不会给出问题根源的直接证据 但真的掌握了以后 已经足以完成大部分的优化诊断工作了

      返回目录高性能MySQL

      编辑推荐

       ASP NET MVC 框架揭秘

       Oracle索引技术

       ASP NET开发培训视频教程