在开源数据库上我们要关注SQL解析问题吗

传统的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不需要像我们那样经常面对痛苦的共享池问题，那个问题像幽灵一样，没有任何迹象，说啥时候爆发就啥时候爆发。那时候，半夜被电话铃声吵醒的时候，害怕共享池出问题的恐惧甚至甚过数据库宕机。