MySQL之性能剖析和Schema与数据类型优化(一)

性能剖析总结

• 1.定义性能最有效的方法是响应时间
• 2.如果无法测量就无法有效地优化，所以性能优化工作需要基于高质量、全方位及完整的响应时间测量
• 3.测量的最佳开始点是应用程序，而不是数据库。即使问题出在底层的数据库，借助良好的测量也可以很容易地发现问题
• 4.大多数系统无法完整地测量，测量有时候也会有错误的结果。但也可以想办法绕过一些限制，并得到好的结果(但是要能意识到所使用的方法的缺陷和不确定性在哪里)
• 5.完整的测量会产生大量需要分析的数据，所以需要用到剖析器。这是最佳的工具，可以帮助将重要的问题冒泡到前面，这样就可以决定从哪里开始分析会比较好
• 6.剖析报告是一种汇总信息，掩盖和丢弃了太多细节。而且它不会告诉你缺少了什么，所以完全依赖剖析报告也是不明智的
• 7.有两种消耗时间的操作:工作或者等待。大多数剖析器只能测量因为工作而消耗的时间，所以等待分析有时候是很有用的补充，尤其是当CPU利用率很低但工作却一直无法完成的时候
• 8.优化和提升是两回事。当继续提升的成本超过收益的时候，应当停止优化
• 9.注意你的直觉，但应该只根据直觉来指导解决问题的思路，而不是用于确定系统的问题。决策应当尽量基于数据而不是感觉。

总的来说，解决性能问题的方法首先是要澄清问题，然后选择合适的技术来解答这些问题。如果你想尝试提升服务器的总体性能，那么一个比较好的七点是将所有查询记录到日志中，然后利用pt-query-digest工具生成系统级别的剖析报告。如果是要追查某些性能低下的查询，记录和剖析得方法也会有帮助。可以把精力放在寻找哪些消耗时间最多的、导致了糟糕的用户体验的，或者那些高度变化的，抑或有奇怪的响应时间直方图的查询。当找到了这些"坏"查询时