本节书摘来自华章计算机《Oracle数据库性能优化方法论和最佳实践》一书中的第1章，第1.7节，作者：柳遵梁 潘敏君 应以峰著，更多章节内容可以访问云栖社区“华章计算机”公众号查看
1.7 Oracle性能优化的神话和误区
Oracle性能优化工作是Oracle数据库科学最为神秘莫测的领域，自然也就会流传着各种传言和八卦。本书最主要的目的就是真正使Oracle性能优化成为一门严谨的科学，使任何阅读并且理解本书内容的读者可以比较简单地完成Oracle性能优化工作，使自己在其他人面前成为“巫师”或“神秘的对象”。
1.7.1 艺术和科学
从百度、Google等网站搜索“性能优化艺术”，会出现大量的条目，部分Oracle性能优化的图书也是直接以“艺术”作为书名的。艺术是什么？艺术是一种具有美感的事物，而美感的事物通常都是因人而异的，自然也就缺乏基本的衡量了。由于大部分人都不具备艺术细胞，因此艺术就成为少部分人的特权，这样Oracle性能优化也就成为少部分专家的专利。性能优化工作被表述为艺术，可能部分是因为基于资源瓶颈分析的方法论的流行，按起葫芦浮起瓢，由于资源之间的相互瓶颈转换，使性能优化工作有时候需要进行平衡，而平衡向来被称之为艺术。本书希望可以打破这种专利，帮助广大的DBA和开发者以科学的观点来看待性能优化，以科学的方法来完成性能优化，而不是依赖于灵感。
Oracle性能优化要从艺术成长为科学，必须完成以下几项基本工作：
性能优化的结果可测量、可量化。
性能优化的大量相关性可以被量化，具有相对客观的标准。
性能优化的改善必须可测量、可量化，具有高度严谨性。
1.7.2 Oracle业务系统性能优化是高手的专利
大量初级DBA对性能优化望而却步，甚至部分高级DBA对性能优化也摸不透。事实上，性能优化是方法重于知识、经验和技术的工作，也许正是这个原因导致了性能优化成为难题。其实，性能优化工作者不需要精通Oracle，不需要对所谓的内核做深入的研究，甚至很多场景下先后顺序理解错误都不会影响优化工作的成效，总之不需要他有多精通Oracle。性能优化工作者真正需要的是具有广泛的知识和视野，具有全局性观点和流程观点，具有较好的客户沟通能力，等等。笔者学习Oracle数据库不到1年就开始独立做电信营业系统的综合性大型性能优化工作，并且取得了良好的效果，笔者不认为那时候自己有很强的Oracle
技术。
虽然有科学的方法和体系做引导，相比于其他工作，性能优化工作还是具有一定的特殊性，阿里巴巴的一则招聘广告在某种程度上反映了性能优化工作需要的素质和知识：
1.?职位描述
1）对大型互联网应用的性能测试、分析、优化等进行研究，形成方法论、流程和自动化工具。
2）通过对OS、JVM、中间件、应用等的优化，提升服务器资源的综合利用率。
3）根据容量情况，推进生产系统的整体优化和综合优化，降低TCO。
4）指导容量规划和管理工作。
2.?岗位要求
1）熟悉大型分布式网站开发、性能优化或运维工作，知识面广、综合技能强，性能优化工作经验优先。
2）熟悉Linux OS、Nginx、Haproxy、Apache，以及Java中间件应用，熟悉网络协议。
3）掌握多种性能诊断、问题解决的技巧和思路。
4）具有良好的沟通能力和执行力，具有钻研精神。
1.7.3 测试系统性能很好，生产系统为什么不行
类似的描述还有“某某用户运行得很好，为什么在你这里就不行？”
任何业务系统都在一个独特的上下文中运行，业务系统运行的好坏很大程度上不是依赖于业务系统本身，而是依赖于业务系统运行上下文环境。回到前面的宝马汽车案例，宝马汽车开得快慢，绝大部分场景下不取决于宝马汽车本身，而在于宝马汽车运行的上下文环境，比如司机、天气、路况等，时空环境决定了宝马汽车的速度，同样它也会决定业务系统的运行速度。
1.7.4 针对特定性能问题的标准解决方案
再次说明，性能问题总是与上下文环境相关的，自然，其解决方案也与上下文相关。比如宝马汽车速度慢，不同的环境下需要不同的改善方式，当然也可以说，如果针对每个环境因素给出改善方案，其性能就会得到优化。不过由于环境的复杂性，现实中似乎不太可能完全做到。在业务系统中，性能问题正是在上下文复杂性这点上表现出了与故障问题截然不同的方向，故障问题绝大部分是由于数据库本身的部件出现故障引起的，因此其解决方案通常都是一致的，上下文很少会影响到故障的处理方法。
一个擅长处理故障的高级DBA，未必就可以很好地处理性能优化问题。经验的堆积可以造就具有相当水平的故障处理高级DBA，但未必就可以造就一个具有相当水平的优化DBA。掌握科学的处理方法是优化DBA最为重要的课题。无法完成在方法上的突破，再多的经验积累也不能造就一个充满信心的优化DBA。
1.7.5 只要资源充足，数据库性能就不会差
资源（比如CPU、内存、IO Subsystem）只是数据库性能表现的一个方面，比较而言，并发性或者吞吐量才是数据库性能中更加重要的影响因素。事实上，国内企业比较喜欢硬件资源高配化，因此往往有大量的资源处于空转状态，性能问题会伴随着这些高配的业务系统而频繁发生。
从另一个角度来看，对于DSS或批处理系统，大量的空闲资源无法被充分利用是业务系统性能问题的一个典型特征。业务性能优化中有一句行话：没有经过优化的系统总是倾向于I/O瓶颈，而经过优化的系统总是倾向于CPU瓶颈。这句话包含两方面的含义。
CPU几乎总是IT业务系统中最为昂贵的部件，任何不被利用的CPU资源都会表现为极大的资源浪费。
CPU几乎是IT业务系统中唯一一个主动驱动部件，任何其他资源和部件之上的活动都来源于CPU的驱动，只有全速的CPU运行才有可能发挥其他部件和资源的可能
作用。
1.7.6 只要数据库性能好，业务系统性能必然良好
对于DBA来说，形成这个观点很自然，因为每个人都把自己擅长的事情看成是最重要的，甚至是唯一的。可惜随着业务系统的复杂化，数据库在业务系统影响链条中的地位会越来越低，数据库的性能只是业务系统性能的一个环节——一个相对重要的环节（见图1-9），也许未来业务系统的进一步发展会导致数据库只是存储数据的最后一个环境，甚至不会对用户交互响应产生直接影响，那时数据库对于业务系统性能就是一个无关紧要的环节。
1.7.7 降低等待时间就可以提高业务系统性能
Oracle Wait Interface（OWI）方法是如此之有效，因而有广大的用户，尤其是其类似于故障排除的思维方式，更是在DBA中成为金科玉律。OWI对于大部分DBA来说是一个福音，使其不需要去关心真正的性能优化科学方法论，就可以延用故障排除的思路来完成性能优化，不断积累的性能优化场景可以在OWI方法中获得价值的最大化。
因为response time = service time + queue time，所以OWI方法的拥护者认为只要降低queue time就可以提高业务系统性能。这个观点在吞吐量压力达到一定程度的业务系统中具有相当的正确性，不过并不是真理。采用OWI方法的用户必须要注意方法适用的场景，不要越界。OWI方法在面临下面的场景时将不再适用：
在低吞吐量的系统中，因为在此系统中很难观察到所谓的等待。
当Oracle等待时间目前无法评估CPU Queue时间，而是简单地标记为CPU时间时。
当Oracle等待时间目前无法评估无效的CPU操作，比如latch spin和mutex spin操作，这些操作都被评估为CPU时间而不是等待时间时。
下面来看一个简单的queue time和latch/mutex事件示例。
某业务系统性能响应缓慢，表现为大量cache buffer chain latch wait。有相当多的性能优化者把增加spin count作为优化的首选措施。但spin操作并非是有效的操作，它仅仅是将标记为wait的时间转移到了CPU的消耗中，变成了service time。这个参数增加之后，很多性能优化者会发现latch等待时间减少了甚至不见了，但是业务系统性能并没有改善。
再次看一下公式：response time = service time + queue time。增加spin count的结果就是：queue time大幅度减少，service time增加（甚至是不成比例的增加）。当然，相当多的性能优化者发现增加这个参数确实能改善性能，甚至会把这种改善方法作为一种灵丹妙药，从而用来优化让人讨厌的latch等待时间。不幸的是，在很多场景下增加这个参数的效果并不好，甚至可能会使性能问题进一步恶化。spin count的唯一作用在于压榨CPU的使用，在CPU有一定空闲的前提下，spin count的增加常会带来好处。但实际情况是，若真正有大面积的latch等待事件，那么CPU资源往往是同步紧张的，这种情况下增加spin count通常会带来反作用，也许正确的做法可能是降低spin count，释放CPU资源在latch上的占用。
