[[442501]]

传统的Oracle DBA皆会把SQL阐发问题看的很严重，这实验上是来自于早年的DBA对分享池问题的怯生生。实验上，我刚刚初始战役数据库的时辰，SQL阐发根柢不是一个什么工夫问题，因为当时辰的办事器的性能有限，酌夺两颗CPU，几十M的物理内存，固然链接了几十台上百台结尾，实验上大多数时辰皆在处理前端清晰等平安的外设操作。信得过打听数据库的并发量并不大，因此当时辰的数据库问题主要照旧DB CACHE的射中率问题，只消保证DB CACHE射中率高于80%，大多数SQL皆能跑的还不错。不外当时辰的SQL也皆比拟肤浅，码农的教授也比拟高，我方能用算法措置的事情一般不会交给数据库去作念。

不事自后跟着C/S架构的发展，前端的并发量越来越大了，微型机办事器的处理才调也大了起来，95年，DEC公司推出了VLM和VLDB的认识，VLM即是VERY LARGE MEMORY，VLDB即是VERY LARGE DATABASE，这是因为64位的芯片出生了，这个芯片即是ALPHA 21064,这个现时一经卖身成为申威的芯片是宇宙上第一颗商用的64位芯片。由于内存一下子进入了GB级别，数据库的界限也从MB级别造成GB级别的了，C/S架构又让前端的并发量有了质的栽种，因此和shared pool干系的问题渐渐多了起来。而固然一经进入了VLM期间，不外当时辰的HP/IBM们还独一32位的芯片，哪怕是64位的办事器上，要配备好几个GB的物理内存依然是格外奋斗的。因此当时辰的数据库SHARED POOL的成立皆是格外哀怜的，200M以上的SHARED POOL就算是比拟豪华的了，恰是因为这个原因，分享池带来的并发争用时时会成为DBA的恶梦。

哪怕自后内存稍稍宽松一些了，不错成立较大的分享池了，当时辰办事器的CPU照旧过于奋斗，因此怎样让CPU把更多的资源用于SQL实施，Oracle在CURSOR分享凹凸足了大功夫，尽可能地让一个CURSOR编译后的资源梗概被更多的会话和实施分享。这个责任让分享池变得格外复杂，也造成了一个格外容易出问题的组件。90年代末00年代初的DBA皆在分享池问题上吃过大苦头。因此大皆的文档良友皆对分享池问题，硬阐发问题作念了大皆的分析。而从DBA这个师父带门徒的面容传承的行状上，这种怯生生被一代代的传了下来。

至少在5年前，还时时有DBA和我探讨数据库性能问题的时辰，皆会把硬阐发数目放在比拟进军的位置上去研讨。我要费挺大的劲儿去诠释，硬阐发固然多了点，然而你的系统问题主要不是硬阐发引起的，因为分享池的争用并不严重。

固然说，Oracle 10g推出了SGA 动态调遣工夫之后，分享池引起的大问题渐渐少了许多，而跟着办事器工夫的发展，非常是去IOE期间初始的X86替代微型机之后，内存，CPU变得格外低廉了。因此咱们的办事器皆不错配备了超豪华的CPU/内存/IO资源了，照旧有大皆的DBA依然受到当时辰的影响，对SQL阐发格外怯生生。这个怯生生致使带到了开源数据库和国产数据库上。

实验上，在大多数开源和国产数据库上，并不存在全局分享的CURSOR，一般来说，CURSOR分享是会话级的。这种计算让Oracle 复杂的分享池结构关于开源数据库来说变得肤浅的多了，它们只需要分享字典缓存就不错了，SQL实施的CURSOR结构在会话内分享就不错了。这种基于会话的CURSOR分享，对DBA来说满盈是一个福音，因为这种结构格外肤浅，辞谢易出现闩锁的问题。

当数据库在高并发SQL实施的时辰，只需要加多极少点SQL阐发的CPU和内存支拨就不错了。而这两种资源在现时的办事器上，一经是格外低廉了。因此在开源和国产数据库上，咱们很少传说SQL阐发引起的性能问题。除非是CPU或者内存资源严重不及的系统中，这类问题只怕皆不是问题。

接纳会话内分享CURSOR是硬件发展的势必遴荐，新数据库也没必要再去研发Oracle那种复杂的分享池了，这关于数据库产业来说是件善事，因为信得过梗概玩转复杂的分享池的，现时杀青也独一Oracle一家。前阵子有个数据库研发东说念主员和我探讨，他念念在他们的自研数据库里引入雷同Oracle的分享池，从而减少SQL阐发的支拨。我残酷他不要这样作念，一条比拟烂的SQL破钞的CPU内存资源，就不错把他们花数千万研发出来的分享池从简的那点哀怜的资源一说念破钞掉，致使成十倍百倍的破钞掉，有阿谁钱还不如进入到改善CBO优化器上去。

红运的是，现时的DBA不需要像咱们那样时时濒临灾祸的分享池问题kaiyun官方网站，阿谁问题像鬼魂相似，莫得任何迹象，说啥时辰爆发就啥时辰爆发。当时辰，深夜被电话铃声吵醒的时辰，狭隘分享池出问题的怯生生致使甚过数据库宕机。