性能优化漫谈之七：性能优化的误区

       误区一、性能优化是一门艺术。
       从百度，Google搜索性能优化艺术，会出现大量的条目，尤其是相对多的Oracle性能优化书籍直接以艺术作为书名。艺术是什么，艺术是一种具有美感的事务，美感的事务必然是因人而异缺乏基本的衡量。由于我们大部分人都不具备艺术细胞，艺术是少部分人的特权，这样Oracle性能优化也就成为了少部分所谓艺术专家的专利了。
      Oracle性能优化，尤其是其目标的完全可量化确定决定了其是一门科学而不是一门艺术，当然这里所的是科学而不是技巧。为什么是Oracle性能优化时科学？ 第一：性能优化的结果可测量，可量化。第二：性能优化的大量相关性可以被量化，具有相对客观的标准。第三：性能优化的改善必须可测量，可量化，具有高度的严谨性。
      性能优化工作被表述为艺术，可能还有一个基于资源瓶颈分析的方法论流行的部分原因，按起葫芦浮起瓢，由于资源之间的相互瓶颈转换，使性能优化工作有时候需要进行平衡，而平衡向来被称之为艺术。
      误区二、性能优化工作需要对Oracle有深入的了解，需要深入了解业务，需要什么什么，反正是全面的高手
      大量的初级DBA对于性能优化望而却步，甚至相当多的高级DBA对于性能优化也云里雾里，导致性能优化成为少部分所谓高手的专利是导致这个观点流行的罪魁祸首。性能优化是方法重于知识，经验和技术的工作，也许是这个原因导致了性能优化的困难。事实上，性能优化工作者不需要要求精通Oracle，不需要对于所谓的内核做深入的研究，甚至很多场景下先后次序理解错误都不会影响性能优化工作者的成效，总之不需要他具有多精通Oracle。性能优化工作者真正需要的是具有广泛的知识和视野，具有全局性观点和流程观点，具有较好的客户沟通能力等等。从我个人而言，我学习Oracle 1年就开始独立做电信营业系统的综合性大型性能优化工作，并且取得良好的效果，我不认为那时候我具有很深的Oracle水平。刚好这里有个阿里巴巴的招聘，某种程度上反映了性能优化工作需要的素质和知识：   

职位描述

岗位描述：
1、对大型互联网应用的性能测试、分析、优化等进行研究，形成方法论、流程和自动化工具；
2、通过对OS、JVM、中间件、应用等的优化，提升服务器资源综合利用率；
3、根据容量情况，推进生产系统的整体优化和综合优化，降低TCO；
4、指导容量规划和管理工作。
岗位要求：
1、熟悉大型分布式网站开发、性能优化或运维工作，知识面广、综合技能强，具有性能优化工作经验优先；
2、熟悉Linux OS、nginx、haproxy、apache，以及java中间件应用，熟悉网络协议。
3、掌握多种性能诊断、问题解决的技巧和思路；
4、具有良好的沟通能力和执行落地能力，具有钻研能力。
     误区三、测试系统性能很好，生产系统为什么不行？
     类似的描述还有某某用户运行的很好，为什么在你这里就不行？
    任何业务系统都在一个独特的上下文中运行，业务系统运行的好坏很大程度不依赖于业务系统本身，而是依赖于业务系统运行上下文环境。回到前文的宝马汽车案例，宝马汽车开的快慢，绝大部分场景下不决定于宝马汽车本身，而在于宝马汽车运行的上下文环境，司机、天气、路况等等，时空环境决定了宝马汽车的速度，同样时空环境决定了业务系统的运行速度。
     误区四、针对特定表现的性能问题，有一套标准的解决方案
     再次说明，性能问题总是和上下文环境相关，其解决方案自然也和上下文相关。就比如说宝马汽车速度慢，不同的上下文需要不同的改善方式，当然也可以说你如果穷尽了所有上下文，针对每个上下文给出改善方案。不过由于上下文环境的复杂性，现实中似乎不太可能做得到。性能问题正是在这点上表现出了和故障问题截然不同的地方，故障由于是数据库本身部件的故障，绝大部分情况其解决方案是一致的，上下文很少会影响到故障的处理方法。
    误区五、只要资源充足，数据库性能就不会差。
    资源只是数据库性能表现的一个方面，比较资源而言，并发性或者吞吐量是数据库性能更加重要的一个影响因素。另外还存在着资源没有被充分利用的问题。
    误区六、主要数据库性能好，业务系统性能必然好。
    对于DBA来说，这个观点很自然，每个人都把自己擅长看做是最重要的。可惜随着业务系统复杂化，数据库在业务系统影响链条中的地位越来越低，数据库的性能只是业务系统性能的一个环节，一个相对重要的环境。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/92650/viewspace-774644/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/92650/viewspace-774644/